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SECTION  1 
INTRODUCTION 


The  advent  of  the  microcomputer  has  revolutionized  the  field  of 
computer  technology  in  much  the  same  way  that  the  transistor  revolution¬ 
ized  the  field  of  electronics  design.  Simulators  have  characteristically 
been  designed  around  large,  high  speed,  general  purpose  computers. 

The  microcomputer,  on  the  other  hand,  is  usually  employed  as  a  stand¬ 
alone,  dedicated  subsystem  component.  The  concepts  of  the  stored 
program,  "fetch  and  execute"  architecture  are  common  between  the  two 
but  the  similarity  does  not  go  much  further.  For  example,  the  memory 
of  the  microcomputer  is  distinctively  divided  into  program  instructions 
and  data  storage.  Instructions  are  stored  in  an  unalterable  read  only 
memory  (ROM  or  PROM)  and  variable  data  is  stored  in  random  access 
memory  (RAM).  Thus,  there  are  no  requirements  for  loading  the  pro¬ 
gram  and  there  are  no  memory  overlays.  The  software  is  neatly  arranged 
into  one  functioning  "module"  although  several  software  packages  (also 
called  modules)  may  have  been  linked  together  to  form  the  real-time 
"modules.  "  There  are  no  operating  systems  or  executives  for  the  micro¬ 
computer  in  the  same  sense  as  for  its  larger  brother.  Furthermore, 

(and  this  is  probably  the  most  significant  point),  the  microcomputer 
"software"  is  very  hardware  oriented.  The  liberalizations  and  generali¬ 
zations  concerning  input/output,  memory  access,  and  mathematical 
operations  which  can  be  used  with  the  larger  systems  simply  do  not 
exist  for  the  micro.  The  total  microcomputer  system  design  requires 
that  the  hardware  not  be  separated  from  the  software;  the  designer  must 
thoroughly  understand  both.  Similarly,  a  discussion  of  the  software 
must  include  at  least  a  relevent  discussion  of  the  hardware. 

This  introduction  is  meant  to  aid  the  reader  in  analyzing  the 
approach  which  was  taken  in  developing  this  document.  In  many  cases 
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the  words,  terminology  and  even  general  concepts  of  DI-H-3277/M4  do 
not  apply  to  the  microcomputer.  On  the  other  hand,  some  topics  (such 
as  hardware  related  material)  has  been  included  although  not  called  for 
in  the  DID.  As  one  might  suspect  from  the  foregoing  discussion,  the 
title  ’’Computer  Program  Documentation"  does  not  completely  describe 
the  true  nature  of  this  document.  However,  the  following  sections  are 
developed  to  correspond  as  closely  as  possible  with  sections  required  by 
DI-H-3277/M4. 
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SECTION  2 

SOFTWARE  ELEMENT  FAMILY  TREE 


The  entire  control  loader  software  was  written  in  the  Intel  high- 
order  microcomputer  language  called  PLM  (PL/M- 80),  with  the  excep¬ 
tion  of  the  analog-to-digital  conversion  routine  which  was  programmed  in 
assembly  language.  The  programs  were  structured  into  a  utility  module, 
a  scan  module,  and  a  simulator  module.  As  the  name  implies  the  utility 
module  provided  system  support  in  the  form  of  calibration  and  test  rou¬ 
tines,  system  interface  procedures,  and  system  initialization.  The  scan 
module  causes  twelve  of  the  available  sixteen  A-to-D  converter  channels 
to  be  scanned  sequentially  and  the  converted  values  to  be  placed  in  the 
appropriate  RAM  locations  for  later  use.  The  simulator  module  contains 
the  frame  rate  generator,  simulator  initialization  routines,  and  the  simu¬ 
lator  equations  themselves.  These  three  modules  were  independently 
compiled  and  linked  into  machine  code.  The  executable  machine  code 
was  placed  in  PROM  (programmable  read  only  memory).  The  variable 
data  and  equation  coefficients  are  placed  in  RAM  (Random  Access  Memory) 
during  real-time. 

The  software  is  best  described  by  structuring  it  into  elements  as 
illustrated  in  Figure  2.  1.  The  elements  that  reside  in  the  utility  module 
are  designated  by  a  "U";  the  simulator  elements  by  an  "S".  The  scan 
module  is  shown  as  a  separate  entity. 

The  "main  program"  is  entered  whenever  a  reset  occurs.  It  initial¬ 
izes  all  system  parameters  and  immediately  calls  the  simulator  into 
action.  The  executive  is  actually  part  of  the  main  program  and  it  admin¬ 
isters  to  the  six  programs  (0  through  5)  of  the  microcomputer.  When  a 
program  is  terminated,  control  returns  to  the  executive.  Since  the  simu¬ 
lator  is  one  of  these  programs,  an  exit  from  it  will  pass  control  to  the 


executive  regardless  of  how  it  was  entered.  The  scan  module  is  only 
used  by  the  simulator  for  analog  input  purposes.  In  addition,  the  simula¬ 
tor  contains  its  own  routine  for  changing  the  equation  coefficients  and 
constants. 


Figure  2.  1  Software  Elements  Family  Tree 


SECTION  3 

TRAINING  PROGRAM  OPERATION  OVERVIEW 

This  section  is  designed  to  provide  an  overview  of  the  software 
system  structure  and  event  sequencing,  memory  allocation  and  simula¬ 
tion  framing  control.  Due  to  the  nature  of  the  microcomputer  the  soft¬ 
ware  requires  no  loading,  nor  an  operating  system  for  control.  Therefore, 
only  overview  items  which  are  relevent  to  the  microcomputer  system 
are  discussed. 

3.  1  SOFTWARE  SYSTEM  STRUCTURE 

System  control  always  resides  in  either  the  executive  (see  Figure 

2.  1)  or  in  the  simulator.  The  simulator  is  simply  an  "infinite  loop"  of 
statements  which  continuously  (120  times  per  second)  solves  the  control 
loading  equations.  It  accepts  data  inputs  through  the  analog  input  inter¬ 
face  (and  scan  module)  and  controls  the  force  on  the  stick  through  the 
analog  output  interface.  The  only  way  to  exit  the  simulator  is  through  the 
parameter  change  routine  in  which  case  control  passes  to  the  executive. 

The  executive  queries  the  system  operator  (through  the  teletype)  for  a 
program  number  which  it  executes  immediately.  When  a  program  is 
exited  (including  the  simulator)  control  passes  once  again  to  the  execu¬ 
tive.  The  teletype  also  plays  a  roll  in  the  parameter  change  routine  in 
that  the  operator  specifies  which  parameter  is  to  be  changed  and  to  what 
value.  The  operator  can  also  select  whether  to  return  to  the  simulation 
or  to  pass  control  to  the  executive  at  this  time. 

3.  2  MEMORY  ALLOCATION 

The  microcomputer  system  is  equipped  to  accomodate  8K  (four 
2716's)  of  programmable  read  only  memory  (PROM)  and  2K  (eight  2113's) 
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of  random  access  memory  (RAM).  The  three  modules  (utility,  simulator 
and  scan)  were  independently  compiled  and  linked  into  a  single  object 
module  which  was  placed  in  the  PROM.  Certain  PLM  library  routines 
were  linked  into  the  object  module  also.  The  exact  locations  of  the 
modules  and  routines  in  PROM  is  relatively  unimportant  since  none  of 
the  PROM  locations  are  alterable.  However,  this  type  of  detailed  infor¬ 
mation  can  be  gotten  in  the  cross-reference  listing  and  the  link  and 
locate  maps  (see  Volume  3).  At  this  point  it  is  sufficient  to  say  that 
the  PROM  memory  lies  in  the  lowest  area  of  memory  since  execution 
starts  at  location  0  (see  Figure  3.  1).  Presently  6820  (decimal)  loca¬ 
tions  of  the  PROM's  are  actually  used  out  of  the  available  8096.  Vari¬ 
ables  are  stored  in  RAM  which  starts  at  3800  H  (hex).  Only  500  of  the 
available  2000  locations  are  used.  The  upper  portion  of  memory  is 
reserved  for  the  peripheral  circuit  boards  in  a  memory  mapped  I/O 
configuration.  The  analog-to-digital  converter  (ADC)  has  a  base  add¬ 
ress  at  F700H,  the  digital-to -analog  converter  (DAC)  at  F708H,  and 
the  high  speed  mathboard  at  FFF0H. 


3.  3  COMPILING,  LINKING  AND  LOCATING 

The  three  modules  involved  in  this  simulator  were  individually  com¬ 
piled  or  assembled  into  executable  machine  code.  Each  module's  machine 
code  then  had  to  be  linked  together  so  that  they  could  interact  as  a  unit. 
This  single  block  of  machine  code  and  the  address  references  within  it 
had  to  be  properly  located  so  that  it  performed  properly  in  the  System 
80/20.  All  of  these  functions  were  performed  using  the  services  of  the 
Intel  ISIS-H  operating  system  as  described  in  the  following  paragraphs. 

3.  3.  1  Compiling 

The  Utility  and  Simulator  Modules  were  written  in  PL/M-80, 
Intel's  high  order  langugae.  The  compiler  is  called  PLM80  and  it  is 
invoked  through  ISIS  by  executing  PLM80  and  specifying  the  source  code 
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Figure  3.  1  Memory  Allocation 


file  name  and  the  desired  compiler  options.  The  compiler  commands 
for  the  Utility  (CNTU6.  SRC)  and  Simulator  (CNTS85.SRC)  modules  were 
respectively: 


PLM80  :F1:CNTU6.  SRC  SYMBOLS  DEBUG  XREF  PAGE  WIDTH  ( 132) 
PLM80  :F1:CNTS85.  SRC  SYMBOLS  DEBUG  XREF  PAGE  WIDTH  (.1321) 

The  :F1:  specifies  that  at  the  time  of  compilation  the  source  file  resided 
on  disk  drive  number  1.  An  explanation  of  the  options  and  other  features 
of  the  compiler  can  be  obtained  in  the  ISIS- II  PL/M-80  Compiler  Operator's 
Manual.  As  a  result  of  executing  the  above  commands,  two  object  files 
are  created  on  disk  drive  1  with  the  names  CNTU6.  OBJ  and  CNTS85.  OBJ 
respectively. 

Similarly,  the  Scan  Module  source  SCAN.  SRC  is  assembled 
into  object  code  by  executing  the  following  ISIS  command: 

ASM80  :F1:SCAN.  SRC 

The  optional  compiler  controls  were  incorporated  with  the  source  listing 
and  an  explanation  of  these  can  be  obtained  from  the  ISIS- II  8080/8085 
Macro  Assembler  Operator's  Manual.  This  assembler  likewise  produces 
an  object  file  with  the  same  generic  name  as  the  source;  namely, 

SCAN.  OBJ. 

3.  3.  2  Linking 

The  three  object  files  must  now  be  linked  together  into  one 
unit.  In  addition,  certain  routines  from  the  PLM  library  are  required 
as  a  result  of  using  the  PLM  compiler.  The  task  of  unifying  these  four 
files  into  one  unit  of  concise  machine  code  is  the  job  of  the  ISIS- II  linker 
called  LINK.  A  description  of  this  program  can  be  obtained  from  the 
ISIS- II  System  User's  Guide.  The  actual  link  command  for  this  project 
can  be  obtained  from  the  link  listing.  It  merely  specifies  that  LINK  is 
to  link  :F1:CNTU6.  OBJ,  :F1;CNTS85.  OBJ,  :Fl:SCANOB J,  and  PLM80.  LIB 
to  a  new  file  called  CNT85.  LNK  on  disk  drive  number  1. 


The  object  code  file  for  the  system  now  resides  in  a  disk 
file  called  CNT85.  LNK.  This  file  must  be  adjusted  so  that  the  execu¬ 
table  code,  the  variables  and  other  factors  lie  in  the  proper  location. 

This  is  the  task  of  program  LOCATE  which  is  also  described  in  the 
ISIS-n  System  User's  Guide.  The  exact  command  used  to  invoke  this 
program  can  be  obtained  from  the  locator  listing.  This  listing  contains 
the  final  addresses  of  all  the  system  parameters  including  the  address 
of  the  starting  location  of  the  code  for  each  line  in  the  PLM  listings. 

The  final  object  code  for  the  entire  system  is  located  in  a  file  called 
CNT85.  It  is  this  code  which  was  programmed  into  the  system  PROM's. 

3.  4  SIMULATION  FRAMING  CONTROL 

Program  execution  starts  from  location  0  which  is  in  the  "main" 
program.  A  series  of  initializations  are  performed  and  control  passes 
to  the  simulator.  The  simulator,  in  turn,  initializes  certain  parameters 
and  functions,  one  of  which  is  the  frame  rate  generator.  This  generator 
is  a  procedure  which  loads  a  hardware  counter.  This  counter  is  decre¬ 
mented  by  the  system  clock  while  the  simulator  is  calculating  the  control 
loading  values.  When  all  three  control  axes  have  been  calculated  and  the 
values  have  been  written  to  the  DAC's,  the  simulator  waits  for  the  counte 
to  decrement  to  zero  which  fires  an  interrupt  (at  level  1).  This  interrupt 
re- initializes  the  frame  rate  generator  and  allows  control  to  pass  back 
to  the  beginning  of  the  simulator  loop.  Thus,  it  can  be  seen  that  the 
frame  time  available  for  computation  is  held  constant  8.  33  milliseconds 
(1/120  second)  while  the  actual  time  consumed  in  computation  will  vary 
according  to  the  processing  requirements  of  each  axis.  The  worst-case 
(maximum)  amount  of  time  for  all  computation  is  approximately  7.  8 
milliseconds.  This  maximum  occurs  when  all  three  actuators  are  in  the 
linear  portion  of  their  ranges.  Figure  3.  2  illustrates  the  relative  times 
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consumed  for  scanning  the  analog  input  channels  and  for  the  calculations 
associated  with  each  axis. 
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Figure  3.  2  Frame  Timing 
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SECTION  4 

CONTROL  LOADING  FORCES  AND  EQUATIONS 


4.  1  SIGN  CONVENTIONS 

Since  the  McFadden  Control  Loader  was  used  in  the  simulator,  we 
elected  to  adapt  our  sign  conventions  to  it.  Table  4.  1  summarizes  the 
maximum  stick  parameters  and  the  sign  conventions  of  the  McFadden 
control  loader  and,  thus,  of  the  overall  system.  The  stick  and  rudder 
pedal  displacements  produced  one  volt  for  every  inch  of  travel  at  the 
McFadden  interface  even  though  the  mechanical  limits  prohibited  travel 
over  a  full  10  inches  (corresponding  to  the  analog  full  scale  of  10  volts). 

All  other  parameters  are  scaled  to  10  volts  at  their  maximum  value.  The 
displacement  and  velocity  parameters  are  obviously  control  loader  outputs 
(computer  inputs)  and  the  force  is  a  control  loader  input  (computer  output). 
Thus,  if  the  stick  is  moved  aft  (positive  direction,  positive  voltage  output) 
an  opposing  force  is  produced  by  the  computer  which  places  a  negative 
voltage  input  to  the  control  loader  resulting  in  a  forward  force. 


TABLE  4.  1  SIGN  CONVENTIONS 


Axis 

Parameter 

Positive 

Direction 

Max  Value 

Pitch 

Displacement 

Aft 

7  in  (5  in  forward) 

Velocity 

Aft 

50  in/sec 

Force 

Aft 

150  pounds 

Roll 

Displacement 

Right 

7  inches 

Velocity 

Right 

60  in/sec 

Force 

Right 

100  pounds 

Yaw 

Displacement 

Right  Rudder 

3.  25  inches 

Velocity 

Right  Rudder 

50  in/sec 

i  orce 

Right  Rudder 

200  pounds 

1 


Thus,  if  we  select  positive  directions  for  control  notion,  velocity, 
and  force  to  be  aft  stick,  right  stick  and  right  pedal  forward,  the  output 
feel  force  will  properly  oppose  the  pilot  action. 


The  control  loading  forces  are  functions  of  control  position  and 

velocity.  In  the  cases  of  the  pitch  and  roll  axes,  we  base  all  forces  on 

the  motion  of  the  top  of  the  control  stick  in  inches  and  inches  per  second. 

Control  stick  aftward  is  positive  displacement  (X  )  and  positive  velocity 

e 

(X  ).  Thus,  positive  X  results  in  upward  elevator  trailing  edge  (nega- 
e  e 

tive  elevator  angle,  6^)  and  the  aircraft  moves  toward  a  nose  up  attitude. 

Positive  pilot  force  (F  )  is  aftward  while  the  resulting  control  loading 

force  (F  )  is  forward  (negative)  so  that  the  net  force  on  the  control  stick 
s 

is  (F  +F  )  in  the  positive  X  direction.  Positive  displacements,  veloci- 
p  s  e 

ties,  control  angles  and  forces  are  illustrated  in  Figure  4.  1 


Control  stick  right  giving  right  aileron  trailing  edge  up  is  positive 
X  ,  X  ,  and  5  .  The  aircraft  moves  toward  right  wing  low.  Positive 

^  cl  3. 

forces  are  shown  in  Figure  4.  1 


In  the  case  of  the  yaw  axis,  positive  displacement  (X  )  and  velocity 
(Xr)  is  right  rudder  pedal  forward.  This  gives  right  rudder  deflection 
(&r)  which  is  negative  and  the  aircraft  moves  toward  nose  right.  Positive 
pilot  force  is  forward  on  the  right  pedal  while  negative  force  is  forward 
on  the  left  pedal. 


4.  2  LOADING  FORCES  DUE  TO  CONTROL  VELOCITY  AND  POSITION 

In  an  airplane  without  power  assist  the  opposing  force  the  pilot  feels 
is  due  to  mechanical  stops  or  friction  in  the  control  members  plus  the 
hinge  moment  which  must  be  overcome  to  hold  the  control  surface  in 
place.  Due  to  the  magnitude  of  these  forces  in  high  speed  flight,  many 
modern  aircraft  have  fully  powered  control  systems  in  which  an  artifi¬ 
cial  feel  system  provides  the  pilot  a  feedback  force  approximately 
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PITCH 


\^~  8e(Neg.) 
Elevator 


ROLL 


YAW 


Forward 


Xa ,  Xq 


Right 


Positive  Aileron  8a 


Xr,  Xr 


Right 


Rudder 
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Figure  4.  1  Sign  Conventions 
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«  proportional  to  the  force  that  would  be  required  without  power.  Sometimes 

the  force  may  be  modified  by  adding  artificial  damping,  for  example.  In 
*  the  simulator,  this  control  loading  (feel)  force  must  approximate,  as 

nearly  as  possible,  the  actual  feel  force  provided  in  the  real  airplane. 

1 

The  simulator  control  loading  force  is  formed  by  adding  together 
various  components,  each  of  which  embodies  a  characteristic  observed 
in  the  actual  airplane  control  loading  force.  The  components  of  loading 
1  force  included  in  the  control  loading  microcomputer  are  described  in 

Table  4.  2 

1  The  components  shown  in  Table  4.  2  are  common  to  many  mechani¬ 

cal  systems.  The  viscous  friction  term  is  the  linear  part  of  the  frictional 
force  and  it  appears  partially  due  to  the  motion  of  the  control  surface  in 
the  fluid  (air).  However  a  certain  level  of  viscous  friction  is  desirable 
for  stability  and  feel  quality.  The  A- 10  aircraft,  for  example,  has  an  eddy 
current  damper  included  as  part  of  the  control  system  to  increase  the 
viscous  damping. 

l 

,  The  coulomb  friction  term  simulates  the  dry  friction  resulting  from 

i  cables,  pulleys,  and  arms  which  necessarily  have  sliding  contact  with 

each  other,  and  with  other  members  in  the  real  airplane.  This  frictional 
1  force  is  of  fixed  magnitude  always  opposing  the  motion  of  the  control. 

The  breakout  force  is  that  force  which  must  be  applied  to  get  any 

i 

mechanical  system  off  of  "dead  center.  "  It  is  similar  to  lifting  a  weight 
from  a  table.  The  applied  force  must  build  up  to  at  least  equal  the 

i 

weight  force  before  the  weight  will  move.  Likewise,  in  causing  a  pulley 
j  wheel  to  turn,  the  applied  torque  must  build  up  to  equal  the  load  torque 

before  the  wheel  will  turn. 

1  Deadband  represents  the  freeplay  in  a  mechanical  system  around 

the  trim  or  equilibrium  position  of  the  control.  The  freeplay  is  caused 
1  by  such  things  as  cable  slack  and  loose  fittings.  The  deadband  may 
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TABLE  4.  2  CONTROL  LOADING  COMPONENTS 


Name 


Characteristic 


Mathematical 

Desienation 


Viscous  Friction 


Coulomb  Friction 
(Dry  or  Sliding  Friction) 


k  sign  (X)  or 
k(X/  |X  |) 


Breakout  (Preload) 


k  sign  (X-X,  .  ) 

trim 


Deadband 


Feel  Spring 


Position  Limiter 


Velocity  Limiter 


- >X-X^  . 

a  ,  trim 
or  6 


X-X^  . 
trim 


[u(6  -a)+u(-6  -a)]F(6 ) 
where  u(6  )  is  the 
unit  step  function 
and  where 

5  =  X-  X  . 

trim 

k.  (6  -  6.  )+b. 
l  ii 

c  ontinuous ,  but 

with  discontinuous 

slope.  Here 

6  =  X-X  . 

trim 

k(X-b)  if  X*b 
0.  for  -a<X<b 
k(X+a)  if  Xs-a 


k(X-a);  Xia 
k(X+a);  x^-a 


exist  either  right  at  the  cockpit  control  or  elsewhere  in  the  system  such 
as  at  the  elevator  actuator  in  the  tail.  Actually,  deadband  exists  through¬ 
out  the  system  at  every  interface  between  members. 

The  feel  spring  force  represents  the  hinge  moment  of  the  control 
surface.  Since  most  modern  aircraft  have  fully  powered  control  systems, 
a  feel  spring  is  included  to  artificially  provide  the  pilot  a  force  suitably 
like  that  due  to  hinge  moment.  In  the  aircraft  simulator,  the  feel  spring 
force  is  made  as  nearly  like  the  aircraft  feel  spring  as  possible.  Hinge 
moment  varies  with  control  surface  deflection,  angle  of  attack,  trim 
angle  and  dynamic  pressure  so  the  feel  spring  may  reflect  all  of  these 
variations.  Usually,  the  feel  spring  force  is  a  nonlinear  function  of 
control  deflection  which  may  be  made  dependent  on  dynamic  pressure. 

The  position  limit  force  represents  the  physical  limit  on  motion  of 
the  control.  When  the  position  limit  is  reached,  the  pilot  must  feel  a 
realistic  hard  stop  just  like  the  hard  stop  he  feels  in  the  aircraft.  The 
feel  of  the  stop  is  better  if  there  Is  a  high  gradient  of  force  build-up 
rather  than  the  sudden  application  of  a  high  force.  Also,  the  high  fre¬ 
quency  content  of  the  force  signal  is  less. 

Aircraft  control  systems  usually  impose  limiting  velocities  of 
motion  of  the  control  stick  and  rudder  pedals.  These  result  from  non- 
linearities  in  the  various  system  elements  or  they  may  be  deliberately 
imposed.  Limiting  velocities  are  desirable  in  that  they  protect  the 
system  components  from  damage.  Like  the  position  limiting  force,  the 
velocity  limiter  is  depicted  as  a  high  force  build-up  when  the  velocity 
exceeds  the  limit. 

4.3  BOBWEIGHT  FORCES 

The  inertial  effects  of  the  aircraft  accelerations  upon  the  parts 
of  the  control  system  affect  the  control  loading  forces.  These  inertial 
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I 

I 

I 

I 

I 

I 

I 

I 

I 

1 

* 

I 
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forces,  referred  to  as  bobweight  forces,  may  be  calculated  when  the  air¬ 
frame  motion  variables  are  known.  Perhaps  the  greatest  contributions 
to  the  bobweight  forces  come  from  the  control  surfaces  themselves  except 
when  the  control  system  is  fully  powered.  In  that  case,  the  aircraft  con¬ 
trol  system  may  include  an  actual  bobweight  (as  in  the  A- 10^  to  provide 
an  inertial  stick  feel  force.  A  bobweight  may  sometimes  be  used  only  in 
the  pitch  axis  (A- 10).  If  the  aircraft  control  system  has  bobweight  forces, 
these  should  be  present  in  the  simulator  control  loading  system  also. 

Consider  an  idealized  bobweight  attached  to  the  airplane  as  shown 
in  Figure  4.2.  The  bobweight  obviously  will  exert  an  inertial  moment  on 
the  control  stick.  We  assume  the  motions  are  restricted  to  the  plane  of 
the  paper.  Then  the  dynamic  acceleration  acting  at  the  CG  of  the  air¬ 
plane  is: 

a^  =  (w-Uq  9)  =  UQ(a-q)  (Positive  downward)  (4.1) 


In  g-units,  with  positive  g's  meaning  upward  acceleration,  we  have: 


N  = 
z 


U 

-f 


(4.2) 


Thus,  we  see  how  angle-of-attack  rate  and  pitch  velocity  lead  to  z- 
directed  acceleration.  Positive  G-acceleration  will  result  in  the  bob- 
weight  trying  to  rotate  downward  and  a  forward  stick  force  will  be  felt  by 
the  pilot.  If  the  bobweight  has  mass,  m,  and  weight,  W,  we  have: 

F  =  F  =  -(m-a  )-S/R  (4.3) 

s  p  z 


F  =  - 
s 

Symbols  defined  in  Figure  4.  2. 


w  -  c 

—  •  (-N  •  g)*  c/R  =  W  —  N 
g  z  R 


z 


dynamic  z-acceleration  is  total  z-acceleration  minus  1. 


I 


/ 
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z 


mass  =  m  =  W/g 
Moment  of  inertia 
about  A=  me2 


d  Bobweight  In  Pitch  Axis 


If  the  airplane  experiences  an  angular  acceleration  about  its  CG 
(q),  the  bobweight  will  lag  behind.  For  a  positive  q  (pitch  up),  the  bob- 
weight  will  try  to  rotate  downward  creating  a  forward  stick  force  as 
shown: 


m(c-f-B)qc  _  W(c+B)c _ 

57.  3R  "  57 .  3gR 


(4.4) 


where  q  is  in  degrees  per  second  per  second. 


The  total  bobweight  feel  force  is  the  sum: 


F 

s 


Wg(C+B) 
57.  3gR 


q 


(4.5) 


If  R  =  1. 67  ft,  W  =  6.  26  Lb.  ,  c  =  .  8  ft,  and  B  =  15.  31  ft  we  find: 

F  =  3  N  +  .  0262  q  (4-6) 

3  Z 

as  on  the  A- 10. 


4.4  LIMB  BOBWEIGHT  FORCES 

In  the  presence  of  aircraft  accelerations,  the  pilots  arm  and  hand 
gripping  the  control  stick  will  behave  Like  a  bobweight.  The  limb  will 
try  to  lag  behind  the  inertial  airplane  accelerations  and  the  pilot  must 
exert  forces  to  hold  the  stick/limb  combination  steady. 

In  vertical  accelerations  and  pitch  accelerations,  the  Limb  bob- 
weight  forces  on  the  stick  would  appear  to  be  mainly  in  the  z-direction 
(vertical)  and  we  have  no  good  way  to  impart  simulated  vertical  stick 
feel  forces  to  the  pilot.  However,  in  side  accelerations  and  roll  accel¬ 
erations,  the  limb  bobweight  forces  on  the  stick  would  be  y-directed 
(sideward)  and  we  can  impart  simulated  side  stick  feel  forces  to  the 
pilot. 
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t  Consider  an  idealized  bobweight,  as  shown  in  Figure  4.  3  simula¬ 

ting  the  pilots  arm/hand  acting  on  the  control  stick.  We  make  the  follow- 
•  ing  simplifying  assumptions: 

1)  Pilot's  body  immobile  except  for  arm. 

1 

2)  Mass  of  arm,  M,  concentrated  at  a  point  distant  from  body. 

3)  Action  of  acceleration  on  arm  simulated  by  stick  force,  F  , 

I  8 

acting  distance  "R"  from  shoulder. 

4)  Arm  a  distance  "B"  above  x-axis. 

1 

5)  The  only  forces  being  considered  are  those  due  to  side  acceler- 

^  ation  (Ny)  and  roll  acceleration  (p). 

I  6)  Arm  motion  limited  to  rotation  about  vertical  axis  except  as 

(  restrained  by  control  stick. 

i 

I 


I 


1 

Figure  4.  3  Limb  Bobweight  Simulation 
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Then  the  Inertial  moment  on  the  arm  (Mi  due  to  side  acceleration, 
N  ,  is  such  as  to  make  the  arm  move  to  the  left.  We  simulate  this 

y 

moment  by  a  stick  force,  F  ,  as  shown,  which  produces  the  same 
moment: 


F  *  R  =  (M  a  l*  l 
s  y 


(4.7) 


F 

s 


(4.  8) 


i 

F  =  Mg  -  N 
s  R  y 


(4.9) 


a 

Here,  a  is  y-directed  acceleration  and— ^-is  N  in  G-units.  This  stick 

y  g  y 

force  and  moment  will  require  the  pilot  to  supply  an  equal  and  opposite 
force /moment  to  keep  the  stick  steady.  Thus  he  is  required  to  supply 
the  same  counter-acceleration  moment  he  would  supply  in  flight  with  a 
side  load. 


The  inertial  moment  on  the  arm  (M)  due  to  roll  acceleration  (pi  is 

such  that  the  arm  would  tend  to  rotate  to  the  left  unless  the  pilot  applies 

a  counteracting  moment.  We  simulate  the  inertial  moment  by  a  stick 

force  F  ,  as  shown,  which  produces  the  same  moment: 
s 

F  *R  =  (M  a  )•  i  (4.  10) 

s  y 


where  a  =  pB 

y 

Then 


F 

s 


MB  l 
R 


P 


If  p  is  in  degrees  per  second  per  second  then: 


F 

s 


MB  l 
57.  3  •  R 


P 


(4.11) 


(4.  12) 
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As  before,  this  stick  force  will  require  the  pilot  to  supply  the 
proper  counteracting  moment  as  he  would  in  actual  flight  with  roll  accel¬ 
eration. 


The  total  limb  bobweight  stick  feel  force  is  the  sum  of  that  due  to 
side  acceleration  and  that  due  to  roll  acceleration: 


N  + 

y 


MBl 


1 57. 3*  R  t 

If  we  take  some  reasonable  values  for  the  parameters: 


(4. 13] 


Mg  =  10  lbs. 

1  =  8"  (.  67  ft) 
R  =  1.  33  ft 
B  =  3  ft 


We  then  have 

Fs  =  5  Ny  +  *  008  P  (4.  14) 

This  is  the  expression  used  for  limb  bobweight  force  in  the  present 
program. 


4.  5  CONTROL  LOADING  EQUATIONS 

Adding  together  all  of  the  sources  of  control  loading  force  discussed 
in  sections  4.  2,  4.  3,  and  4.  4,  we  now  obtain  the  loading  force  for  each 
axis. 

The  microcomputer  task  is  to  calculate  the  stick  (or  pedal)  feel 
force  to  be  input  to  the  force  control  loop  and  generated  by  the  control 
loading  actuator.  Information  on  the  A- 10  furnished  by  the  Air  Force 
was  for  a  two-degree-of-freedom  system  for  each  axis  (see  Appendix  A). 
We  have  consolidated  each  axis  as  a  single  degree-of-freedom  system 
as  follows: 
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4.  5.  1  Pitch 


F  =  .  64  X  +  1.5  sign  (X  ) 

s  e  e 


2.  5  sign  (X  -X-  .  ) 

e  'trim 


viscous 

friction 


coulomb  friction 


breakout 


+  3.  N  +  .  0262  q  +  F_X  +  F  , 

z  F  P  travel  lim. 


bobweight 


feel  spring  (-6.7  in.  aft, 
+2.  7  in.  fwd.  ) 


vel.  lim. 

(±5.  236  in/ sec) 


(4. 15) 


V  1 


X  =  position  of  stick-grip  (fore  &  aft),  inches.  (Positive 


Xgtrim  =  integrated  output  of  on-off  trim  switch. 

=  dynamic  normal  acceleration. 

q  =  pitch  acceleration,  degrees  per  second  per  second. 

Fj.  -  a  piecewise  linear  function  of  (X^-Xg^^)  with  break 
points  as  shown  in  Table  4.  3. 

X  =  a  function  dependent  on  hinge  moment.  It  is  primarily 
*  a  magnification  factor  sensitive  to  dynamic  pressure. 


(Xp  =  1  in  present  program.  ) 


4.  5.  2  Roll 


F  =  .  06  X  +  1.5  sign  (X  )  +  2  sign  (X  -Xat  .  ) 

s  a  -  a  a  ‘‘trim 


viscous 

friction 


coulomb  friction 


breakout 


+  4.5  (X  -X,  +  5  N 


a  trim  p 


008p 


(4.  16) 


feel  spring 


limb  bobweight 
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TABLE  4.  3  PITCH  FEEL  SPRING  BREAK  POINTS 


f. 


travel  lim. 
(±3.  1  inch) 


vel.  Lim. 
(±6.  5  in/sec) 


X  =  lateral  position  of  stick-grip,  inches  (positive  right), 
a 

Xa  =  integrated  output  of  on-off  trim  switch. 

atrim 

N  =  lateral  G-force. 

y 

p  =  roll  acceleration,  degrees/sec/sec. 

X  =  magnification  factor  dependent  on  hinge  moment 

^  (X  =  1.  in  present  program). 

P 

No  apparent  deadband  in  roll  for  A- 10. 


4.  5.  3  Yaw 


F  =  .905  X  +  4.  25  sign  (X  )  +  5.  sign  (X  ) 


viscous 

friction 


coulomb  friction 


breakout 


(4.  17) 


+  15.  X  X  +  F  ... 

r  p  travel  lxm. 


+  F 


feel  spring 


(±3.  5  in) 


vel.  lim. 
(±11. 9  in/ sec ) 


No  rudder  trim  shown  on  A- 10  data. 

No  deadband  shown. 

X  =  rudder  pedal  position,  inches  (left  pedal  fwd.  is 
positive). 


X  =  magnification  factor  dependent  on  hinge  moment 

**  (X  =  1.  in  present  program). 

P 


4.6  CONTROL  LOADING  LOOP 

The  University  elected  to  attempt  to  simulate  the  entire  control 
loading  loop  (pitch  axis  only)  to  gain  confidence  in  our  understanding  of 
the  system  prior  to  actually  wiring  up  the  hardware.  The  basic  part  of 
the  loop  is  a  two-stage,  electrohydraulic  valve /actuator  which  generates 
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the  feel  force  for  the  pilot  to  sense.  Reference  4  discusses  this  type  of 
valve.  Figure  4.  4  is  a  block  diagram  of  what  we  feel  is  a  reasonable 
representation  of  the  loop.  Note  that  the  expression  for  actuator  torque 
is  nonlinear  so  the  responses  were  obtained  by  an  iterative  technique. 

Throughout  the  system  estimates  were  made  of  time  constants  and 

dimensions.  The  step  response  of  this  system  is  included  in  Section  5.  2 

of  this  report.  This  response  was  obtained  by  simulating  the  control  loop 

on  the  University's  computer.  We  did  not  use  the  airframe  equations  in 

this  simulation  so  airframe  variables  such  as  dynamic  pressure,  N  , 

z 

N  ,  q,  p,  and  trim  were  not  available.  Also  travel  limits  and  velocity 
limits  were  not  used. 

We  begin  a  brief  description  of  the  control  loop  operation  at  the 

right  side  of  Figure  4.4  where  the  pilot  force  is  input  to  the  control  stick. 

The  difference  between  the  pilot  force  and  the  opposing  actuator  force 

(F  )  causes  acceleration  of  the  stick  grip  leading  to  stick  velocity  (X  ) 

A  6 

and  position  (Xfi).  X^,  being  the  velocity  of  the  stick,  determines  the 
flow  rate  (Q)  through  the  hydraulic  valve. 

Stick  position  and  velocity  are  furnished  to  the  microcomputer  for 
use  in  generating  the  command  stick  feel  force  (Fg).  The  test  results 
shown  in  Section  5  included  only  viscous  friction,  breakout  force,  and 
feel  spring  force  among  the  components  of  F^. 

The  command  force,  F  ,  is  next  compared  to  the  actual  actuator 

s 

force,  F.,  giving  an  error  signal  (F  -F  ).  The  error  voltage  leads  to 

3  A 

valve  current,  i  ,  and  valve  spool  position,  x  ,  through  appropriate 
v  sp 

transfer  functions  as  shown. 

The  actuator  steady  state  torque  is  a  nonlinear  function  of  valve 
current,  spool  position,  and  flow  rate.  The  steady  state  actuator  gener¬ 
ated  stick  force,  FF,  is  calculated  assuming  a  control  stick  length  of  20 
inches.  Since  steady  state  conditions  are  not  arrived  at  immediately,  a 
time  delay  smoothing  transfer  function  converts  FF  to  F^  which  is  the 
actual  actuator  force. 
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The  nonlinearity  in  the  torque  expression  necessitated  use  of  an 
iteration  procedure  to  obtain  convergence  for  each  update  of  actuator 
feel  force.  The  step  response  shown  in  Section  5.  2  was  for  an  input  ten 
(10)  pound  pilot  step  force.  The  response  is  seen  to  be  very  fast  as  it 
must  be  to  be  realistic.  The  force  overshoot  seen  after  9/120  second 

is  necessary  to  decelerate  the  stick  and  reach  an  eventual  constant  stick 
displacement. 

Constants  for  Figure  4.4  (assumed) 

-  .02  inches /milleamp 
Tj  =  . 0002  sec  * 

K3  =  2.  inches3 

Pg  =  1500.  psi.  (supply  pressure) 

Cz  =  20.  in3/sec/(pound)1/2 
=  .  1  inches 2 
T^  =  .  01  sec"* 
m  ~  *0222  pound  sec  /inch 


t 


I 


l 


i 


i 


i 


* 
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TOROUE=Sign(iv)Ks(Ps-(^jp)8  ) 


Figure  4.4  Control  Loading  Loop 
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SECTION  5 

COMPUTER  PROGRAM  SYSTEM  DESCRIPTIONS 


The  entire  control  loader  software  was  written  in  the  Intel  high- 
order  microcomputer  language  called  PLM  (PL/M-80),  with  the 
exception  of  the  analog-to-digital  conversion  routine  which  was  performed 
in  assembly  language.  The  programs  were  structured  into  a  utility 
module,  a  scan  module,  and  a  simulator  module.  As  the  name  implies 
the  utility  module  provided  system  support  in  the  form  of  calibration  and 
test  routines,  system  interface  procedures,  and  system  initialization. 

The  scan  module  causes  twelve  of  the  available  sixteen  A-to-D  converter 
channels  to  be  scanned  sequentially  and  the  converted  values  to  be  placed 
in  the  appropriate  RAM  locations  for  later  use.  The  simulator  module 
contains  the  frame  rate  generator,  simulator  initialization  routines,  and 
the  simulator  equations  themselves. 

5.  1  GENERAL  PROCESSING 

Processing  starts  in  the  utility  module  after  a  reset  (push  button 
reset  or  power-on  reset).  As  illustrated  in  Figure  5.  1  the  system  hard¬ 
ware  is  initialized  first.  The  simulator  module  is  entered  next  which, 
in  turn,  initializes  the  needed  equation  parameters  before  starting 
through  the  simulator  loop.  If  no  request  is  pending  (at  the  teletype  key¬ 
board)  the  loop  is  executed  120  times  per  second,  solving  equations  for 
all  three  axes.  If  a  request  for  a  change  is  made  by  the  system  operator, 
he  has  the  option  to  exit  the  simulator  processing  and  enter  the  execu¬ 
tive.  If  he  elects  to  make  a  parameter  change  he  can  continue  to  make 
as  many  changes  as  he  desires  before  re-entering  the  simulator  loop.  If 
the  operator  chooses  to  leave  the  simulator,  control  will  pass  to  the  exe¬ 
cutive  which  will  request  a  program  number.  Programs  0  through  4  are 
self  test  and  calibration  routines  which,  once  completed,  will  pass 
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U  =  Utility  Module 
S  =  Simulator  Module 

*LOOP  EXECUTED 
120  TIMES /SECOND 


Figure  5.  1  General  Flowchart 
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control  back  to  the  executive.  Program  5  is  the  simulator  and,  if  selected, 
will  re -initialize  all  the  simulator  parameters  to  their  original  value 
befoie  entering  the  simulator  loop. 

5.2  THE  UTILITY  MODULE 

The  utility  module  contains  the  main  program  for  the  system. 

This  program  initializes  the  appropriate  hardware  and  software  items 
in  a  procedure  called  INITIALIZE.  It  then  enters  (calls)  the  simulation 
loop  contained  in  the  Simulator  Module.  However,  if  the  operator  termi¬ 
nates  the  simulation,  the  system  then  returns  to  the  Utility  Module  and 
requests  a  command  from  the  console  operator  by  typing: 

CONTROL  LOADER  EXECUTIVE 
WHICH  PROGRAM? 

Depending  on  the  console  operator's  input,  it  calls  the  appropriate  pro¬ 
cedure.  These  procedures  include  various  test  and  calibration  routines 
as  well  as  the  simulator  procedure  itself.  The  table  below  lists  the  pro¬ 
cedure  which  will  be  executed  when  a  particular  input  is  supplied 

INPUT  PROCEDURE 

0  MATHBOARD  TEST 

1  ADC  TEST 

2  GAIN  TEST 

3  DAC  TEST 

4  RAMP  TEST 

5  SIMULATOR 

The  following  subsections  discuss  the  various  elements  and  procedures  in 
the  Utility  Module.  Flowcharts  for  these  Utility  Module  procedures  are 
contained  in  Appendix  A.  The  above  mentioned  procedure  INITIALIZE 
performs  initialization  functions  for  many  different  hardware  items.  It 
is  therefore  more  efficient  to  discuss  the  portions  of  INITIALIZE  with 
those  respective  items. 


5.  2.  1  Declarations 


The  utility  module  contains  two  kinds  of  declaration 
statements  "literal"  and  "type.  "  The  literal  definitions  can  be  observed 
in  the  program  listing  and  are  merely  macro  or  literal  word  substitutions 
for  certain  quantities.  They  are  grouped  according  to  function  and  they 
also  appear  in  the  simulator  module  so  that  the  same  words  may  be  used 
in  both  modules.  For  example,  the  teletype  input  port  is  defined  by  set¬ 
ting  the  word  CONSOLE$IN  functionally  equivalent  to  the  SBC  80/20  port 
number  of  'EC.  1 

The  type  declarations  are  standard  PLM  statements 
which  declare  the  variable  names  as  being  either  "byte"  or  "address" 
types.  All  of  the  variables  are  declared  as  being  public  so  that  the  simu¬ 
lator  module  may  share  the  locations. 

5.  2.  2  Teletype  Communications 

During  the  initialization  subroutine,  INITIALIZE, 
the  various  functions  are  performed  to  set  up  the  communication  section 
of  the  hardware  for  teletype  usage.  There  are  two  hardware  components 
involved  in  this  section:  the  8251  Programmable  Communication  Inter¬ 
face  (PCI  or  USART)  and  the  8253  Programmable  Interval  Timer  (PIT). 

Only  one  of  the  counters  in  the  8253  (counter  #2)  is 
used  for  communication  purposes;  it  generates  the  baud  rate  for  the  PCI. 
Counter  #2  is  dedicated  to  the  baud  rate  function  and  is  initialized  by  first 
writing  the  appropriate  control  word  to  the  8253  followed  by  the  "divide- 
by"  count  (see  Section  3.9.1  and  3,9.2  of  the  System  80/20  Hardware 
Reference  Manual).  The  control  word  was  synthesized  to  reflect  the 
following  attributes: 
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Select  Counter  #2 

(10) 

Load  LSB,  MSB 

(ID 

Mode  3 

(11) 

Binary  Counter 

(0  ) 

Therefore,  the  control  word  B6  (hex)  is  output  to  the  control  word  register 

at  port  DF.  7.’he  baud  rate  factor  ("divide-by"  count)  is  next  written  to  the 

counter  register  (port  DE),  low  byte  first.  This  baud  rate  factor  is 

0263,,  or  611  .  It  is  determined  by  taking  the  closest  integer  value 

lo  10 

which  results  from  a  calculation  involving  the  desired  baud  rate  (110  bits/ 
sec),  the  8251  baud  rate  multiplier  (16)  and  the  basic  clock  period  (930  ns). 
Thus  the  baud  rate  factor  is 


I 


610.95  or  611 

1 

110  X  16  X  930ns 

1 

With  the  BRF  =  611  the  actual  baud  rate  is 

109.99  bits  per  second  -  very 

t 

close  to  110. 

1 

Similarly  the  8251  USART  is  initialized  with  two 

i 

words  •  a  mode  word  and  a  control  word  (see  Section  3.  7,  80/20  Hardware 

1 

Reference  Manual).  The  mode  word  (CE  hex)  was  synthesized  for  the 

l 

following  functions: 

I 

Baud  Rate  Multiplier  =  16 

(10) 

1 

Character  Length  =  8  bits 

(ID 

Parity  Disabled 

(0  ) 

i 

Parity  Odd 

(0  ) 

f 

Stop  bits  =  2 

(U) 

J 

1 

The  control  word  is  35,,  and  was  synthesized  for  the  following  functions: 

10 

Transmit  Enable 

(  1  ) 

f 

Data  Terminal  Not  Ready 

(0  ) 

Receive  Enable 

(  1  ) 

Send  Break-Normal 

(0  ) 

1 

Error  Reset 

(  1  ) 

Request  to  Send  Active 

(  1  ) 

Internal  Reset 

(0  ) 

1 

Hunt  Mode  Disabled 

(0  ) 

f 
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Both  the  mode  word  and  the  control  word  are  written  to  port  ED;  the  mode 
word  must  be  written  first.  As  described  in  the  80/20  references,  the 
data  port  is  EC. 


5.  2.  3  Console  Input /Output 


The  communications  which  are  conducted  between 
the  system  and  the  operator's  teletype  (TTY)  is  provided  by  the  following 
procedures; 


CONSOLES  OUTPUT 

CONSOLE$INPUT 

HEX$OUT 

HEX2$OUT 

LINE$1NPUT 

PRINT 

CRLF 

FIX$TO$ASCH 
ASCII$  TO  $  FIX 


The  desired  communication  proceeds  one  character  at  a  time  and  thusly 
the  CONSOLE$INPUT  and  CONSOLE$OUTPUT  procedures  perform  their 

respective  functions  on  one  character.  If  the  character  to  be  output  is  a 
hexadecimal  value  (4- bits)  the  procedure  HEXOUT  is  used  to  convert  the 

value  to  an  ASCII  character  and  subsequently  call  CONSOLE$OUTPUT. 
Similarly,  in  HEX2$OUT,  a  single  byte  (8-bits)  is  converted  to  two  ASCII 
characters  which  are  output  in  successior.  high  order  first.  If  an  entire 
line  of  input  is  required  from  the  operator,  the  procedure  LINE$INPUT  is 
executed  which  places  the  ASCII  character  images  sequentially  into  an 
array  called  LINE$BUF  and  also  provides  the  calling  routine  with  the  char¬ 
acter  count.  The  line  is  terminated  by  the  operator  with  a  carriage  return. 
On  the  other  hand,  if  a  line  of  text  is  to  be  displayed  on  the  console,  the 
PRINT  procedure  is  used.  This  procedure  requires  the  address  of  the 
first  character  to  be  displayed.  All  characters  are  sequentially  output  to 
the  console  until  an  "ETX"  (03)  is  encountered.  The  CRLF  procedure  out¬ 
puts  a  carriage  return  (CR)  and  a  line  feed  (LF)  to  the  console  when  it  is 
invoked. 
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The  FIX$TO$ASCII  and  ASCII$TO$FIX  procedures 
communicate  with  the  console  operator  and  convert  data  between  a  string 
of  ASCII  numeric  characters  and  the  equivalent  16- bit  value.  FIX$TO$ASCII 
takes  the  value  of  a  parameter  called  RESULT,  converts  it  to  a  string  of 
ASCII  numeric  characters  and  outputs  the  string  to  the  console  (preceeded 
by  a  message  such  as  "RESULT  =").  ASCII$TO$FIX  performs  the  oppo¬ 
site  function.  It  accepts  a  string  of  decimal  characters  from  the  console 
(followed  by  a  CR),  converts  the  string  to  a  hexadecimal  value  and  sets 
RESULT  equal  to  that  value.  These  two  procedures  make  extensive  use 
of  the  above  mentioned  procedures  as  well  as  the  EXECUTE  procedure 
which  is  discussed  later  in  this  section.  The  method  employed  is  to  suc¬ 
cessively  divide  (or  multiply)  the  parameter  by  a  factor  of  10.  For 
example,  in  FIX$TO$ASCII  the  hexadecimal  value  to  be  converted  is 
divided  by  "multiplier"  of  10000  (since  the  maximum  hexadecimal  value  is 
65,  536).  The  result  of  the  division  is  a  decimal  integer  (0  to  9)  which 
forms  the  first  output  character.  That  character  (times  the  multiplier) 
is  then  subtracted  from  the  original  value  leaving  the  lower  order  digits. 

The  "multiplier"  is  then  reduced  by  a  factor  of  ten  down  to  1000.  This 
routine  of  divide- subtract- divide  is  repeated  four  more  times  to  provide 
5  digits  in  all.  The  five  digits  are  then  output  to  the  console.  ASCH$TO$FIX 
works  in  just  the  opposite  order:  it  accepts  up  to  five  digits,  performs  a 
multiply- add- multiply  routine  and  places  the  value  in  the  parameter 
RESULT. 

5.2.4  Mathboard  Interface 

The  SBC  310  High  Speed  Mathboard  was  supplied  by 
the  manufacturer  with  an  I/O  base  address  of  C8  selected.  (See  SBC  310 
HRM,  paragraphs  2-8,  2-9.  )  This  address  was  used  without  change  and 
the  literal  declarations  reflect  this  base  address.  The  memory  base 
address  assignment  is  under  software  control  and  was  established  as 
address  FFFO  hex  at  the  logical  top  of  memory.  (See  SBC  310  HRM, 
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chapter  3.  )  The  various  mathboard  functions  (e.  g.  fixed  point  multiply) 
were  also  defined  in  literal  declaration  (e.  g.  MUL  =  0)  for  later  use. 

(See  SBC  310  HRM,  Table  3-2.  )  The  two  argument  registers  of  the  math 
board  are  32  bits  in  length  which  requires  two  address- type  parameters 
for  data  transfer.  The  "operand"  register  (which  is  also  the  "result" 
register)  is  defined  by  two  names:  OPERAND$IL  and  OPERAND$IH  for 
the  low  and  high  halves  respectively.  Similarly,  the  "operator"  register 
is  defined  by  the  names  OPERAND$2L  and  OPERAND$2H.  All  four  of 
these  parameters  are  "based"  address- type  variables  with  the  addresses 
assigned  in  the  INITIALIZE  procedure.  (See  SBC  310  HRM,  chapter  3.  ) 

The  interface  between  the  mathboard  and  the  system 
is  handled  by  three  procedures: 

•  PERFORM 

•  EQUATE 

•  EXECUTE* 

PERFORM  causes  the  mathboard  to  take  the  action  which  is  defined  by  the 
parameter  OPERATION.  For  example  if  OPERATION  =  0  a  fixed  point 
multiply  will  be  performed  on  the  values  which  are  in  the  argument  regis¬ 
ters.  It  then  waits  for  the  operation  to  be  complete  and  checks  the  error 
flags.  (See  SBC  310  HRM,  paragraph  3-6.)  If  no  error  resulted,  it 
returns  to  the  calling  routine.  If  an  error  was  detected  by  the  mathboard 
(e.  g.  division  by  zero),  PERFORM  causes  an  error  message  to  be  dis¬ 
played  on  the  console  which  states  the  status  code,  opcode  and  the  value 
of  the  two  operands. 

EQUATE  is  a  procedure  which  handles  floating 
point  operations  (32 -bit  operands)  whereas  EXECUTE  handles  fixed  point 
operations  (16-bit  operands).  Both  of  these  routines  proved  to  be  too 
expensive  to  use  in  real-time  but  they  are  employed  in  the  MATHBOARD$ 
TEST  and  ASCII  conversion  procedures.  EQUATE  requires  three  add¬ 
ress  pointers  to  the  32-bit  (4-byte)  locations  of  the  destination,  operand 
and  operator  for  the  floating  point  function.  It  also  requires  the  operation  to 
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be  defined  by  setting  OPERATION  to  the  appropriate  value.  EQUATE  uses 
PERFORM  once  the  operand  and  operator  values  are  loaded  in  the  argu¬ 
ment  registers.  The  result  is  placed  in  the  destination  location.  For 
example 

CALL.  EQUATE  (.RESULT,  .  RESULT,  FPLUS,  .TEMP) 


i 


i 


I 

i 


will  produce  the  same  effect  as  the  following  FORTRAN  statement; 

RESULT  =  RESULT  +  TEMP 

EXECUTE  operates  in  a  similar  manner  except 
that  the  actual  16-bit  values  are  passed  as  opposed  to  addresses.  Thus, 

RESULT  =  EXECUTE  (RESULT,  TIMES,  TEMP) 


I 

I 

i 


has  the  same  effect  as  the  following  FORTRAN  statement; 
RESULT  =  RESULT  *  TEMP 


1 

4 

1 

I 

1 

l 

I 

i 

I 


1 


I 


I 


5.  2.  5  Analog  Input  Interface 

The  analog  input  chores  are  performed  by  the  SBC 
711  Analog  Input  board  and  two  software  subroutines:  ADVAL  in  the 
Utility  Module  and  SCAN  in  the  Scan  Module.  ADVAL  returns  binary 
value  of  the  channel  designated  in  its  argument  list.  SCAN  is  a  routine 
which  permits  a  range  of  channels  to  be  converted  in  a  sequential  manner. 

The  SBC  711  board  had  to  be  modified  by  employing 
the  user  selectable  options  provided.  This  board,  therefore,  has  the 
following  characteristics,  some  of  which  were  modified  from  the  OEM 
configuration.  The  base  address  remains  F700,  as  supplied.  In  addition, 
the  full  scale  range  of  +  lOv  was  not  changed.  The  ADC  trigger  options 
were  not  used  because  the  trigger  is  under  software  control.  The  trans¬ 
fer  acknowledge  delay  was  not  changed  from  the  preset  50  ns.  However, 
the  ,:offset  binary  code"  option  was  selected  by  reconfiguring  the  jumpers 
around  pin  67.  (see  SBC  711  HRM,  paragraph  2-10). 


■ 
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The  software  is  structured  around  "based"  variables 
AICOM,  AIFCR,  AILCR,  AUNT  and  ATVAL  referring  to  the  command 
register,  first  channel  register,  last  channel  register,  interrupt  register 
and  data  registers  of  the  SBC  711,  respectively.  (See  Section  3  of  SBC 
711  HRM.  )  The  command  register  is  initially  reset  in  subroutine 
INITIALIZE. 

Subroutine  ADVAL  merely  follows  the  recommended 
procedures  for  a  random  channel  conversion;  that  is,  AIFCR  is  loaded 
with  the  desired  channel,  the  conversion  is  started  through  AICOM,  the 
subroutine  waits  for  the  status  register  (AICOM)  to  indicate  EOC,  the 
conversion  is  stopped,  and  the  value  returned.  ADVAL  is  used  in  the 
ADCTEST  (program  #1)  subroutine  which  is  the  PLM  equivalent  of  the 
calibration  routines  ADCRNG  and  ADCOFF  in  the  SBC  711  HRM  (Section 
5-5,  Calibration  Procedures). 

For  the  simulator  function,  a  sequential  scan  of 
the  desired  channels  is  performed.  A  full  description  of  this  process  is 
contained  in  the  Scan  Module  section. 

5.  2.  6  Analog  Output  Interface 

The  analog  output  chores  are  handled  by  Intel's 
SBC  710  Analog  Output  Board.  The  analog  output  registers  on  this  board 
appear  as  simple  contiguous  memory  locations  to  the  CPU.  The  base 
address  F708  hex  was  factory  prewired  and  not  changed.  The  process  of 
outputing  an  analog  signal  is  one  of  merely  writing  the  desired  hexadeci- 
aml  value  to  the  appropriate  location.  The  variables  DACO,  DAC1,  DAC2 
and  DAC3  are  based  address- type  parameters  which  refer  to  the  analog 
output  registers.  Thus,  if  the  value  of  RESULT  is  to  be  converted  to  an 
analog  voltage  on  channel  0,  the  PLM  statement  is  merely 

DACO  =  RESULT 

The  only  physical  modification  to  the  SBC  710  was 
to  select  the  "offset  binary  code"  option  as  described  in  Section  3.  1.  3. 
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5.  2.  7  Self  Test  and  Calibration  Routines 

The  Utility  Module  contains  five  procedures  which 
were  written  to  provide  a  means  of  testing  all  three  of  the  peripheral  cir¬ 
cuit  boards  (SBC  711,  SBC  724,  SBC  310)  and  of  calibrating  the  analog 
input  and  analog  output  boards  (SBC  711  and  SBC  724  respectively).  The 
analog  reference  manuals  contain  specific  information  pertaining  to  the 
calibration  of  the  various  amplifiers  and  since  these  units  are  software 
driven  the  manuals  also  contain  sample  programs  which  can  be  used  for 
the  calibration  procedure.  The  procedures  contained  in  the  Utility  Module 
are  PLM  equivalents  of  the  ones  in  the  manuals.  The  system  operator 
selects  the  desired  test  program  on  the  console  by  responding  to  the 
Utility  Module's  request  which  appears  after  leaving  the  simulator  loop: 

CONTROL  LOADER  EXECUTIVE 
WHICH  PROGRAM? 


The  operator  responds  by  typing  in  an  integer  from  0  to  5  which  has  the 
following  meaning: 


Program 

0 

1 

2 

3 

4 

5 


Name 

Mathboard  Test 
ADC  Test 
Gain  Test 
DAC  Test 
Ramp  Test 
Simulator 


The  simulator  function  will  be  discussed  in  Section  3.  2.5.  The  other 
functions  are  described  in  the  following  paragraphs. 

5.  2.  7.  1  Mathboard  Test  (0) 

The  hardware  reference  manual  for  the 
high-speed  mathboard  (SBC  310)  does  not  provide  any  means  of  testing 
this  unit.  Of  course,  there  is  no  calibration  required  since  it  is  entirely 
digital.  Therefore,  a  procedure  MATHBOARD$TEST  was  written  which 
will  accept  an  integer  from  the  console  in  the  range  of  0  to  65535  (2^). 
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This  integer  is  used  to  check  each  mathematical  function  which  the  math- 
board  is  capable  of  performing  which  includes  integer  functions,  floating 
point  functions,  and  the  conversions  between  these  functions.  That  is, 
the  value  supplied  by  the  operator  is  multiplied  by  itself,  divided  by 
itself,  squared,  square- rooted,  etc.  At  the  end  of  the  sequence  of  tests, 
the  last  value  is  printed  on  the  console  and  will  correspond  to  the  value 
supplied  by  the  operator  if  the  test  is  passed.  If  the  value  typed  in  by  the 
operator  is  0  (zero),  the  system  will  type  two  error  messages  since 
division  by  zero  was  performed  twice,  once  in  integer  and  once  in  float¬ 
ing  point.  These  error  messages  relate  the  following: 

a)  Status  (error)  code  -  See  SBC  310  HRM,  p  3-5 

b)  Opcode  which  caused  error 

c)  The  contents  of  the  two  argument  registers  after  the 
error  was  detected 

The  operator  may  also  request  that  the  above  status  information  be 
printed  each  time  the  mathematics  board  performs  an  operation  during 
the  test.  If  this  is  the  case,  a  variable  called  ERR$SW  is  set  equal  to  1; 
otherwise,  ERR$SW  =  0.  The  procedure  PERFORM  recognizes  this 
variable  and  acts  accordingly  in  typing  out  the  status  information.  Refer 
to  Section  3.3  for  a  complete  description  of  the  console  interaction. 

This  procedure  makes  use  of  the 

EQUATE,  EXECUTE  and  PERFORM  procedures  described  previously. 

It  also  uses  the  various  console  input/output  routines  and  also  employs 
the  ASCII  conversion  routines  ASCH$TO$FIX  and  FIX$TO$ASCII,  all  of 
which  were  previously  discussed.  Thus  the  MATHBOARD$TEST  proced¬ 
ure  is  structured  almost  exclusively  from  pre-defined  routines. 

5.  2.  7.  2  ADC  Test  (1) 

The  analog  input  board  hardware 
reference  manual  provides  calibration  programs  which  support  the 
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required  calibration  procedures  (see  SBC  711  HRM,  chapter  5).  How¬ 
ever,  these  programs  (SBC  711  HRM,  Table  3-3)  are  written  in  assembly 
language.  Therefore  the  PLM  procedure  ADCTEST  was  written  which 
incorporates  all  of  the  features  of  the  assembly  language  program 
ADCOFF  (ADCRNG  is  another  name  for  the  same  program).  This  pro¬ 
gram  is  used  to  perform  the  calibrations  associated  with  offset  and  range 
adjustments  (SBC  711  HRM,  paragraphs  5-7  and  5-8  respectively). 

Specifically,  this  procedure  asks  the 
operator  which  analog  input  channel  he  wishes  to  look  at  (channels  0 
through  F  hex).  The  procedure  then  continuously  reads  and  displays  (in 
hex)  the  digital  value  of  the  analog  input  until  a  character  (any  character) 
is  typed  on  the  console.  Control  then  passes  back  to  the  executive.  The 
net  effect  which  this  procedure  produces  is  that  of  a  digital  voltmeter 
which  types  the  values  out  in  hexadecimal. 

5.  2.  7.  3  Gain  Test  (2) 

The  GAINTEST  procedure  was  written 
to  satisfy  the  need  of  performing  a  gain  adjustment  on  the  programable 
amplifier  of  the  analog  input  board  (SBC  711  HRM,  paragraph  5-6).  This 
procedure  incorporates  the  same  features  as  the  assembly  language  pro¬ 
gram  PGAADJ  described  in  the  hardware  reference  manual.  When 
selected  this  procedure  merely  types  "PGA  GAINTEST"  on  the  console 
and  then  enters  a  gain  switching  loop  until  a  character  (any  character)  is 
typed  on  the  console. 

5.  2.  7.  4  DAC  Test  (3) 

The  analog  output  board  is  similar  to 
the  analog  input  board  in  that  its  amplifiers  must  be  calibrated  in  accor¬ 
dance  with  published  procedures  (SBC  724  HRM,  paragraph  5-6).  The 
PLM  procedure  DACTEST  was  written  to  fulfill  the  software  requirements 
for  such  a  calibration.  When  selected,  it  types  the  message 
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DACTEST 
HEX  VALUE? 


to  which  the  operator  must  respond  with  four  hex  characters  such  as 
5B2C.  This  hex  value  is  then  written  out  to  all  four  DAC  channels  which 
in  turn  convert  the  value  to  analog  voltages  at  the  output.  Thus,  if  the 
operator  wishes  to  have  a  positive  full  scale  voltage  (  +  I0v)  at  the  output 
he  must  type  7FF0.  If  he  wishes  to  have  a  negative  full  scale  voltage 
(-10v),  he  must  type  FFFO.  The  hex  values  reflect  the  offset  binary 
(2's  complement)  format  selected  under  the  hardware  modifications.  The 
last  digit  is  zero  because  only  the  most  significant  twelve  bits  placed  in 
the  DAC  are  converted  (12-bit  accuracy).  Control  passes  back  to  the 
executive  immediately  after  execution. 

5.  2.  7.  5  Ramp  Test  (4) 

The  procedure  RAMPTEST  was  written 
to  provide  a  dynamic  signal  on  the  DAC  output  channels.  This  signal  is  a 
sawtooth  ramp  with  a  period  of  approximately  five  seconds.  It  is  achieved 
by  simply  incrementing  a  variable  and  writing  its  value  out  to  all  four 
DAC's  in  a  continuous  loop. 

5.  2.  8  Interupt  Structure 

During  the  initialization  subroutine  INITIALIZE 
three  control  words  are  written  to  the  8259  Programmable  Interrupt 
Controller  (PIC).  The  first  word  is  initialization  control  word  ICW1-C 
which  sets  the  format  interval  to  8  (bit  F  =  0)  and  the  single/slave  flip- 
flop  to  single  (bit  S  =  1).  (See  p  3-107,  80/20  HRM.  )  This  word  also 
transfers  three  address  bits  (A^,  A^,  A?)  to  the  PIC.  The  second  word 
is  ICW2  which  transfers  the  remaining  address  bits  (Ag  -  A^,.)  to  the 
PIC.  The  address  bits  represent  the  location  of  the  interrupt  jump  table 
in  the  software;  the  PIC  inserts  the  lowest  address  bits  (A^  -  A^)  auto¬ 
matically  based  on  the  interrupt  being  services.  At  this  writing,  the 
PL/M  compiler  requires  interrupt  routines  at  the  standard  locations. 


despite  the  capabilities  of  the  8259.  The  third  word  written  is  the  opera¬ 
tion  control  word  OCW1  which  merely  enables  the  desired  interrupts. 
These  words  are  written  to  the  ports  which  are  designated  by  the  hard¬ 
ware  configuration  of  the  80/20;  that  is,  ICW1-C  is  written  to  port  ODAH, 
ICW2  and  OC¥l  to  port  ODBH. 

At  the  end  of  each  interrupt  service  routine  the  "non¬ 
specific  end- of- interrupt"  control  word  OCW2-E  (20H)  is  written  to  port 
ODAH.  This  action  clears  the  particular  interrupt  in-service  (IS)  bit  in 
the  8259  corresponding  to  the  assigned  interrupt  level. 

For  a  full  discussion  of  the  8259  PIC  and  to  ascertain  the 
implications  of  the  above  actions  refer  to  Section  3.  10.  1  (pages  3-87  to 
3-110)  of  the  SBC  80/20  Hardware  Reference  Manual.  Of  particular 
interest  is  the  information  on  pages  3-109  and  3-110  which  describes  how 
the  interrupts  can  be  configured  on  the  80/20  board  itself.  The  interrupt 
structure  is  used  only  for  frame  rate  generation  which  is  discussed  in 
Section  3.  2.  5.  2. 

5.  3  SCAN  MODULE 

The  Scan  Module  is  an  assembly  language  program  which  is  invoked 
by  the  simulator  module  when  the  values  of  the  analog  input  channels  are 
to  be  read.  The  conversion  of  the  12  analog  input  channels  was  previously 
accomplished  with  an  interrupt- driven  PLM  procedure  (subroutine)  and 
consumed  approximately  3  MS  of  processing  time.  No  advantage  was 
realized  from  the  interrupt  structure  since  the  convert  time  (37  pS  per 
channel)  was  much  shorter  than  the  data  handling  software  time.  Addition¬ 
ally,  the  machine  code  resulting  from  the  PLM  statements  was  rather 
inefficient.  Therefore,  the  input  scan  routine  was  converted  to  a  non¬ 
interrupt,  assemply  language  program  which  is  capable  of  converting  all 
12  analog  channels  in  less  than  1  millisecond. 


A  declare  statement  in  the  simulator  module  establishes  the 
following  address -type  (16-bit)  variables  in  contiguous  locations  in  RAM: 
PDOT,  PITCH,  NZ,  QDOT,  ROOT,  ROLL,  NY,  PPDOT,  YDOT,  YAW, 
PTRIMSIG,  RTRIMSIG.  The  order  in  which  they  are  declared  is  the 
order  in  which  they  occur  in  memory.  The  scan  module  causes  input 
channels  0  through  11  to  be  converted  consecutively  with  the  data  from 
channel  0  being  placed  in  PDOT  and  the  subsequent  data  values  in  the  scan 
to  be  placed  in  consecutive  memory  locations  (2  bytes  each).  As  a  result 
the  above  mentioned  variables  take  on  the  value  of  the  corresponding 
analog  input  channel. 

The  scan  process  is  conducted  in  its  entirety  when  a  "call" 
is  made  from  the  simulator  module.  The  simulator  module  first  initial¬ 
izes  the  first-channel-register  and  the  last-channel-register.  It  enables 
the  auto  increment  feature  and  then  starts  the  first  conversion.  (See 
Section  3.  2.  3.  5  for  a  discussion  of  the  registers  involved.  )  The  "call" 
is  then  made  to  SCAN.  The  first  scan  module  operation  is  to  initialize 
the  8080's  DE  register  with  the  address  of  PDOT  and  the  B  register  with 
the  channel  counter  (12).  The  scan  loop  is  then  entered  which  starts  by 
checking  the  analog  input  board  to  see  if  a  conversion  is  in  process,  in 
which  case  the  processor  will  wait  in  a  loop  until  the  conversion  is  com¬ 
plete.  The  channel  value  is  read  (placed  in  the  HL  register)  and  a  new 
conversion  is  started  by  writing  a  03  hex  out  to  location  F700,  the  analog 
input  base  address;  The  value  in  the  HL  register  is  then  written  out  to 
the  destination  specified  by  the  DE  register  which  is  incremented  in  the 
process.  Register  B,  the  channel  counter,  is  decremented  to  end  the 
loop  and  transfer  control  back  to  the  status  check.  When  register  B 
reaches  zero,  the  converter  is  reset  and  control  is  transferred  back  to 
the  simulator  module. 

5.4  SIMULATOR  MODULE 

The  simulator  module  performs  all  the  tasks  necessary  to 
run  the  real-time  simulation.  It  contains  its  own  declarations  (in 
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addition  to  those  of  the  utility  module),  frame  generation  software, 
dummy  procedures,  lead  and  lag  procedures  for  each  axis,  initialization 
statements  and  the  simulation  loop  itself.  The  simulator  is  entered 
immediately  after  a  RESET  and  is  also  one  of  the  programs  (program  5) 
which  the  operator  can  select  under  executive  control.  Upon  entering 
the  simulator,  all  variable  parameters  are  initialized  and  the  simulator 
loop  is  then  entered.  The  loop  is  executed  120  times  each  second,  calcu¬ 
lating  the  forces  for  all  three  axes  in  each  loop.  The  operator  may 
request  a  parameter  change  in  which  case  the  simulation  is  halted  until 
the  desired  changes  are  made.  The  operator  may  also  enter  the  execu¬ 
tive  program  at  this  point.  The  following  paragraphs  describe  the  proced¬ 
ures  associated  with  the  Simulator  Module.  The  corresponding  flowcharts 
are  contained  in  Appendix  A. 

5.4.1  Declarations 

Most  of  the  declarations  in  the  simulator  modult  *re  identical 
to  those  of  the  utility  module  and  actually  reference  them  by  the  EXTER¬ 
NAL  attribute.  Additional  parameters  are  declared  which  are  unique  to 
the  simulator  module.  The  order  in  which  these  variables  are  declared 
governs  the  order  in  which  they  reside  in  memory  and,  therefore,  tne 
order  in  which  they  are  referenced.  For  instance,  the  order  of  the  11 
parameters  following  PDOT  in  the  declaration  determines  the  "parameter 
number"  for  each  when  a  change  is  requested. 

5.4.2  Frame  Rate  Generation 

The  frame  timing  is  generated  by  loading  counter  #0  of  the 
8253  with  the  appropriate  "frame  rate  factor"  (FRF),  counting  down  to 
zero,  and  allowing  the  8253  to  interrupt  the  processor  at  the  terminal 
count  (zero).  The  processor,  therefore,  is  free  to  perform  simulator 
tasks  while  the  8253  is  counting  down.  The  clock  for  this  function  is  pro¬ 
portional  to  the  crystal  controlled  clock  for  the  microprocessor. 


That  is,  the  micro's  clock  is  divided  by  2  before  use  by  the  counter, 
resulting  in  a  counter  clock  period  of  930  nanoseconds.  For  a  frame 
rate  of  120  frames /seconds  the  frame  rate  factor  is 


FRF 


_ 1 

120  X  930  ns 


8960. 57 


The  counter,  therefore,  is  loaded  with  a  value  of  2301^  (8961^). 

Prior  to  operation,  the  8253  is  loaded  with  a  command  word 
in  the  INITIALIZE  procedure.  This  command  word  is  one  which  was 
synthesized  in  order  to  program  counter  #0  of  the  8253.  This  word  has 
a  value  of  30  hex  which  was  produced  from  the  following  attributes: 


Select  Counter  #0 

(00) 

Load  LSB,  MSB 

(11) 

-  -  - 

(0  ) 

Mode  0 

(00) 

Binary  Count 

(0  ) 

(See  Section  3.  9  of  the  80/20  HRM  for  details  of  the  8253  operation.  ) 

The  frame  rate  function  has  been  assigned  the  highest  avail¬ 
able  interrupt  priority  level  -  level  1.  Therefore,  several  items  had  to 
be  considered  to  accommodate  this  interrupt.  First,  the  output  of  8253 
counter  #0  was  connected  to  interrupt  request  1  (IR1)  of  the  8259  Pro¬ 
grammable  Interrupt  Controller.  This  was  accomplished  by  connecting 
together  jumper  pins  25  and  35  on  the  80/20  CPU  Board.  Second,  the 
interrupt  mask  bit  (bit  1)  of  the  8259  must  be  unmasked  (set  to  0)  by 
writing  the  appropriate  word  in  the  proper  sequence  to  port  DB.  (See 
Section  3.  10  of  the  80/20  HRM.  )  Thirdly,  an  interrupt  service  routine 
had  to  be  written  to  handle  the  interrupt  once  it  occurs. 

The  interrupt  service  routine  "FRAME"  uses  the  PLM 
interrupt  procedure  declaration  so  that  the  first  interrupt  instruction  is 
in  memory  location  0008.  This  routine  provides  the  following  functions: 

1.  Restarts  the  frame  counter  by  writing  the  frame  rate 
factor  FRF  to  port  DC,  low  byte  first. 
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2.  Checks  for  framing  errors.  The  frame  rate  switch 
FRSW  is  set  to  zero  at  the  end  of  the  simulator  block. 

If  FRSW  =  1  when  interrupt  1  occurred,  simulator  pro¬ 
cessing  was  not  complete  and  the  on-board  LED  is 
flashed  to  indicate  the  framing  error. 

3.  The  frame  rate  switch  FRSW  is  set  to  1. 

4.  The  logic  level  bit  0  at  J1  (port  E4)  is  inverted  to  indi¬ 
cate  frame  time  available. 

5.  The  non-specific  end- of- interrupt  word  (20  hex)  is  writ¬ 
ten  to  port  DA  to  reset  the  8259  "in-service"  byte  1 
(IS1). 

Framing  is  accomplished  through  the  use  of  the  parameter 
FRSW.  At  the  beginning  of  each  frame  (first  statement  after  the  label 
SIMLOOP  in  the  listing)  FRSW  is  set  to  zero.  At  the  completion  of  the 
equation  processing  the  processor  waits  in  a  loop  for  FRSW  to  change 
from  zero.  This  occurs  in  the  interrupt  routine  FRAME  so  that  when 
control  returns  to  the  "idle  loop"  FRSW  =  1  and  the  loop  is  exitted. 

A  unique  feature  about  this  control  loading  simulator  is  the 
service  provided  by  bits  0  and  1  at  the  digital  interface  on  the  SBC  80/20. 

Bit  0  is  inverted  each  time  FRAME  is  executed  (120  times  per  second) 
and,  when  connected  to  an  oscilloscope,  it  indicates  the  amount  of  frame 
time  available.  Bit  1  is  set  high  at  the  beginning  of  each  frame  (near  the 
label  SIMLOOP  in  the  listing)  and  it  is  set  low  at  the  completion  of  the 
equation  processing  and  thus  it  indicates  the  amount  of  frame  time  consumed. 

5.  4.  3  Dummy  Procedures 

The  simulator  module  employs  several  of  the  pro¬ 
cedures  which  were  defined  in  the  utility  module,  namely  PRINT,  PER¬ 
FORM.  ASCn$TO$FIX  and  FIX$TO$ASCH.  Furthermore  the  SCAN 
procedure  from  the  scan  module  is  also  invoked.  The  dummy  procedures 
declare  that  the  actual  coding  resides  "external"  to  the  simulator  module. 
(See  Section  8.  1,  PL/M- 80  Programming  Manual.  ) 
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5.4.4  Simulator  Processing 

When  a  RESET  occurs  or  when  program  5  is  selected  by  the 
operator  in  executive  mode  the  procedure  SIMULATOR  is  called.  The 
simulator  variables  and  coefficients  are  first  initialized  to  the  appropri¬ 
ate  values,  and  the  frame  generator  is  started.  At  this  point  the  proces¬ 
sor  enters  the  simulator  loop,  SIMLOOP.  The  first  action  taken  is  to 
perform  a  complete  input  of  the  variable  parameters  through  the  routine 
SCAN.  Once  this  task  is  accomplished  the  processor  begins  to  calculate 
the  output  forces:  pitch,  roll  and  yaw  in  that  order.  The  processing  for 
each  axis  proceeds  in  a  manner  as  shown  in  Figure  5.  2.  As  each  force 
is  calculated,  its  value  is  written  out  to  the  respective  DAC  and  proces¬ 
sing  moves  on  to  the  next  axis.  After  the  yaw  computations  are  complete 
and  the  yaw  force  has  been  written  out  to  the  yaw  output  channel,  a  loop 
is  entered  which  causes  the  simulator  to  wait  for  the  end-of-frame  inter¬ 
rupt  as  explained  in  Section  5.4.  2.  The  simulator  then  checks  for  a 
request  from  the  system  console  (teletype).  If  no  request  is  pending, 
control  passes  back  to  the  beginning  of  the  simulator  loop.  If  a  request 
is  pending  (a  key,  any  key,  was  depressed),  the  operator  is  asked  whether 
a  parameter  change  is  being  requested.  If  the  reply  is  negative,  control 
passes  back  to  the  executive  in  the  utility  module.  If  the  reply  is  affirma¬ 
tive  a  parameter  change  routine  is  entered  which  allows  the  operator  to 
examine  the  present  value  of  and  change  the  value  of  as  many  parameters 
as  is  necessary.  Upon  leaving  this  routine  control  passes  back  to  the 
beginning  of  the  simulator  loop.  Each  of  these  blocks  will  be  discussed 
in  detail  within  the  following  paragraphs. 

5.4.  4.1  Simulator  Initialization 

When  control  passes  to  the  simulator  as  a  conse¬ 
quence  of  a  reset  or  the  selection  of  program  5  in  the  executive  all  of  the 
necessary  simulator  parameters  are  initialized  to  their  original  value. 
These  parameters  all  have  storage  locations  in  ramdom  access  memory 
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(RAM)  so  that  they  may  be  changed  by  the  operator  as  necessary.  Further¬ 
more,  all  of  the  changeable  coefficients  reside  in  contiguous  RAM  locations 
so  that  they  may  be  selected  by  number  for  a  change.  (See  Section  6.  6.  3.  2.  ) 
The  ,rby- the -number"  method  was  chosen  over  a  "by-name"  method  due  to 
its  very  simple  implementation  scheme  and  very  significant  reduction  in 
storage  requirements.  The  order  in  which  they  appear  in  the  declaration 
statements  determines  the  respective  reference  numbers.  There  are  a 
total  of  224  such  parameters  but  not  all  are  used  in  the  present  simulation 
because  the  full  capability  of  setting  ten  spring  breakpoints  is  not  fully 
utilized.  These  parameters  and  their  respective  numbers  are  included  in 
Table  5.  1  for  completeness. 

Several  other  parameters  are  also  initialized 
which  are  used  during  processing  for  intermediate  and  final  value  stor¬ 
age.  Furthermore  the  frame  generation  is  started  by  a  simple  call  to 
the  FRAME  procedure.  This  procedure,  as  described  in  Section  5.4.  2, 
loads  the  hardware  counter  with  the  frame  rate  factor  which  starts  the 
frame  timing.  When  the  counter  reaches  zero  an  interrupt  occurs  which 
causes  this  FRAME  procedure  to  be  executed  again  but  this  will  only 
occur  at  the  end  of  the  simulator  loop.  The  initialization  process  is 
concluded  when  all  of  the  bits  on  output  port  E4  (hex)  are  set  low.  Bits 
0  and  1  are  used  to  monitor  the  frame  times  as  described  in  Section  3.  3. 

5.4.  4.  2  Simulator  Loop 

When  control  passes  to  the  beginning  of  the  simula¬ 
tor  loop  at  SIMLOOP,  a  small  amount  of  processing  is  performed  in 
preparation  for  performing  the  scan  of  the  analog  input  channels.  The 
first  operation  is  to  set  the  frame  rate  switch  FRSW  =  0.  This  allows 
the  simulator  to  pause  at  the  conclusion  of  the  calculations  until  the 
FRAME  interrupt  occurs  to  set  FRSW  =  1.  The  next  operation  sets  the 
"frame  time  used"  bit.  Bit  1  at'  Jl,  to  a  high  level.  This  bit  will  be  set 
low  at  the  conclusion  of  the  simulator  calculations  as  an  indication  of 
frame  time  used.  The  next  few  statements  initialize  the  analog  input 
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TABLE  5.  1  (Con't)  PARAMETER  NUMBER  TABLE 


board  as  described  in  Section  5.  2.  5.  The  actual  scan  is  conducted  by 
simply  calling  SCAN,  the  assembly  language  routine  described  in  Section 
5.  3.  At  this  point  the  pitch  equations  are  entered.  The  following  section 
describes  the  operation  of  the  pitch  equations  but  this  discussion  can  be 
extended  to  the  roll  axis  and  yaw  axis  equations  as  well.  In  fact  the  roll 
and  yaw  equations  are  duplicate  copies  of  the  pitch  equations  with  the 
appropriate  coefficients  substituted.  (The  pitch  coefficients  can  be  re¬ 
cognized  by  a  "P"  in  the  variable  name  such  as  KPVTSC.  The  roll  and 
yaw  equivalents  are  KRVISC  and  KYV1SC  respectively.  )  The  yaw  equations 
do  not  require  a  solution  involving  bobweight  effects.  Therefore,  state¬ 
ments  involving  the  bobweight  effects  which  appear  in  the  pitch  and  roll 
sections  are  deleted  from  the  yaw  section.  Similarly,  the  yaw  axis 
(rudder  pedals)  required  no  trim  capability  so  the  statements  pertaining 
to  trim  rate  are  not  included  in  the  yaw  processing  but  yaw  trim  effects 
are  maintained  so  that  the  operator  can  adjust  the  trim  from  the  console. 
These  are  the  only  differences  between  the  processing  of  the  three  axes. 
Therefore,  the  description  of  the  pitch  processing  is  sufficient  to  describe 
all  three  axes. 

5.4.4.  3  Pitch  Processing 

The  pitch  processing  is  illustrated  in  Figure  5.  3. 

The  displacement  direction  is  determined  first  so  that  it  may  be  compared 
to  the  limit  in  the  respective  direction.  If  a  limit  is  exceeded  the  appro¬ 
priate  limit  calculations  are  made  and  the  resulting  value  is  output  to  the 
corresponding  DAC.  If  the  displacement  is  within  limits  it  is  checked 
for  a  value  which  might  lie  within  the  deadband,  in  which  case  the  vari¬ 
ous  dynamic  stick  calculations  are  bypassed.  On  the  other  hand,  if  the 
displacement  is  out  of  the  deadband  those  terms  are  calculated  and,  in 
any  event,  the  bobweight  forces  are  calculated  before  the  force  is  output 
to  the  DAC.  Each  of  the  specific  areas  of  the  pitch  processing  will  be 
discussed  in  detail  in  the  following  paragraphs. 
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Figure  5,  3  Pitch  Processing  Flowchart 
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5.  4.  4.  3.  1  Travel  limit 

The  first  operation  is  to  evaluate  the 
displacement  for  exceeding  one  of  the  travel  limits.  If  the  pitch  is  nega¬ 
tive  (meaning  the  stick  is  forward)  control  passes  to  the  label  NPITCH; 
if  it  is  positive  the  evaluation  is  made  in  sequence.  It  should  be  mentioned 
here  that  '‘negative"  means  a  hexadecimal  value  greater  than  7FFF  which 
is  consistant  with  the  offset  binary  (2's  complement)  convention  set  up 
on  both  analog  boards.  In  either  case  the  pitch  is  compared  with  the 
appropriate  limit  (PLIMAFT  or  PLIMFOR)  and  if  it  is  determined  to  be 
within  limits  control  is  passed  to  the  label  PITCH$DEADBAND  for  further 
processing.  If  the  limit  has  been  exceeded  then  the  difference  (the 
amount  in  excess)  is  multiplied  by  a  gain  factor  KPLIMF.  The  result  of 
this  multiplication  is  tested  for  an  overflow  (a  value  greater  than  the 
positive  limit).  In  this  case  an  overflow  would  occur  during  the  subse¬ 
quent  integration  if  the  result  was  greater  than  3FFF,  half  the  offset 
binary  limit.  If  an  overflow  is  detected  then  the  maximum  opposing  force 
is  commanded  (8000  hex  for  a  positive  displacement,  7FFF  hex  for  a 
negative  displacement)  and  command  passes  to  the  roll  equations.  If  no 
overflow  is  detected  then  command  passes  to  the  procedure  PITCH$FORCE 
which  applies  the  compensation  to  the  force  value.  The  result  of  the 
above  multiplication  (the  amplified  displacement  excess)  is  passed  to 
this  procedure  with  the  proper  sign  (negative  for  aft  displacement,  posi¬ 
tive  for  forward  displacement)  through  the  general  address-type  variable  Al. 

The  PITCH$FORCE  procedure  provides 
a  lag  term  by  integrating  (adding)  the  present  value  with  the  previous 
value  and  it  provides  a  lead  term  through  a  subsequent  procedure  called 
PLEAD.  The  intergration  routine  can  accomodate  up  to  20  terms  but  the 
present  configuration  only  requires  2  which  is  governed  by  the  value  of 
KPLIMLAG.  The  lead  factor  is  added  by  employing  the  pitch  velocity, 

PDOT,  multiplied  by  a  gain  factor  KPLIMLEAD.  However,  due  to  the 
fact  that  the  multiplication  must  be  performed  with  positive  numbers  the 
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velocity  is  first  tested  for  polarity  and  the  absolute  value  of  PDOT  is 
loaded  into  the  operand  register.  The  multiplication  is  performed  and 
a  check  for  an  overflow  is  again  made.  The  resultant  lead  term  is  added 
to  the  integrated  lag  term  and  the  pre- limit  value  of  the  pitch  force, 
PTOT.  PTOT  is  included  so  that  the  spring  and  other  linear  forces  are 
incorporated  in  the  overall  force  value.  A  final  check  for  overflows  is 
made  before  the  force  value  is  written  out  to  the  pitch  output  channel, 
DACO. 


5. 4. 4. 3. 2  Deadband 

If  the  pitch  displacement  is  not  out  of 
the  travel  limits,  control  is  passed  to  the  label  PITCH$DEADBAND.  At 
this  point  the  trim  signal  PTRIM$SIG  is  tested  to  determine  whether  the 
pilot  is  commanding  trim  and,  if  so,  the  direction  of  the  command.  A 
forward  trim  command  is  designated  by  a  +10  volts  on  analog  input  chan¬ 
nel  10;  an  aftward  trim  command  by  a  -10  volts.  The  discrimination  of 
this  signal  is  made  above  +2.  5  volts  (8192  decimal)  and  below  -2.  5  volts 
(5  7344  decimal).  The  trim  is  thereby  shifted  at  a  rate  of  approximately 
one  inch/second  by  adding  (subtracting)  the  pitch  trim  rate  factor, 
PTRIMRATE,  with  the  previous  trim  value.  It  must  be  noted  that 
PTRIM  is  positive  aft,  negative  forward.  Processing  continues,  regard¬ 
less  of  the  trim  processing,  by  initializing  the  total  pitch  force  variable 
PTOT  to  zero.  A  check  is  made  to  determine  whether  the  stick  is  within 
the  deadband.  Trim  is  incorporated  with  the  pitch  value  in  this  determi¬ 
nation  since  the  deadband  travels  with  the  trim  setting.  If  the  net  value 
is  positive  a  comparison  is  made  with  the  aft  deadband  limit,  PDBANDA. 

If  it  is  negative,  the  comparison  is  made  with  the  forward  limit  PDBANDF. 
If  the  stick  is  determined  to  be  within  the  deadband  there  is  no  need  to 
calculate  any  of  the  linear  parameters  so  control  is  passed  to  the  bob- 
weight  equations.  On  the  other  hand  if  the  stick  is  in  the  linear  region 
processing  progresses  sequentially. 
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5.4.  4.  3.3  Spring  and  breakout  forces 


If  the  stick  is  past  a  deadband  limit, 
the  absolute  value  of  this  net  linear  distance  is  used  to  determine  the 
spring  and  breakout  forces.  That  is,  the  processing  is  divided  at  this 
point  based  on  this  net  value  so  that  the  absolute  value  will  be  used  and 
so  that  the  proper  spring  coefficients  are  used.  The  net  value  is  used  to 
also  determine  which  interval  of  the  non-linear  spring  is  to  be  selected. 

A  comparison  is  made  with  the  spring  breakpoints,  the  array  KPSBRKF 
(or  KPSBRKA),  and  the  appropriate  spring  constant  is  selected  from  the 
array  KPSPRINGF  (or  KPSPRINGA).  This  net  distance  is  multiplied  by 
this  spring  constant  and  the  appropriate  offset  element  from  the  array 
KPSOFFF  (or  KPSOFFA)  is  added  to  the  total  force  PTOT.  In  addition, 
the  breakout  force  must  be  added  to  PTOT  before  moving  on  to  the  other 
terms. 

Breakout  was  determined  to  require 
lead  and  lag  compensation  around  the  point  of  the  break.  The  lag  term 
is  incorporated  by  letting  the  value  of  the  breakout  force  be  equal  to 
twice  the  net  displacement  distance  past  the  deadband  limit  until  this 
force  reaches  that  of  the  breakout  parameter  KPBRAK.  The  lead  term 
is  incorporated  to  provide  a  snapping  sensation  at  the  break  point.  This 
is  done  by  adding  the  velocity  multiplied  by  a  gain  factor  called  KPBRJK- 
LEAD  to  the  total  force  PTOT.  However,  this  lead  term  is  only  added 
if  the  stick  is  within  0.  1  inches  (328  decimal  units)  of  the  breakpoint. 
Processing  subsequently  passes  to  the  friction  equations  regardless  of 
the  processing  path  taken  through  the  spring  and  breakout  forces. 

5.  4.  4.  3.  4  Viscous  and  coulomb  friction  forces 

The  viscous  friction  forces  are  calcu¬ 
lated  by  simply  multiplying  the  abosulte  value  of  the  velocity  PDOT  by  the 
viscous  coefficient  KPVISC.  The  coulomb  funtion,  however,  required  a 
small  lag  term  initially.  Therefore  the  force  value  (variable  A2  at  this 
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point)  is  set  equal  to  the  velocity  until  the  value  reaches  the  flat  coulomb 
force  value  KPCOUL.  Both  force  values  are  added  to  the  force  total  PTOT. 

5.4.4.  3.5  Bobweight  forces 

There  are  two  bobweight  force  terms 
to  consider.  The  first  is  the  term  due  to  the  normal  acceleration  of  the 
aircraft  which  is  passed  to  the  microcomputer  from  the  host  computer 
and  is  named  NZ.  This  NZ  term  is  simply  multiplied  by  the  appropriate 
coefficient  KNZ  to  produce  the  resultant  force  which  is  added  to  PTOT. 
Similarly,  QDOT,  the  angular  airframe  acceleration  from  the  host,  is 
multiplied  by  its  respective  coefficient  KQDOT  and  added  to  PTOT. 

5.4.4.  3.6  Force  integration  and  output 

An  empirical  study  revealed  that  the 
force  value  in  the  linear  stick  region  from  the  deadband  limit  to  the 
travel  limit  should  be  smoothed  by  integrating.  Therefore,  the  value 
which  is  finally  written  to  the  DAC  is  the  average  of  the  present  calcula¬ 
ted  value  and  the  previous  value.  This  averaging  is  performed  by  divi¬ 
ding  the  present  value  by  2  (shift  right  one  bit)  and  adding  this  value  to 
the  previous  halved  value.  The  resultant  value  is  written  out  to  DACO 
and  the  present  halved  value  is  saved  for  the  next  frame.  At  this  point, 
processing  passes  on  to  the  roll  equations  and  subsequently  to  the  yaw 
equations. 

5. 4. 4. 3. 7  End -of- frame  routines 

After  the  yaw  equations  are  completed, 
a  series  of  steps  are  taken  which  terminate  the  processing  for  the  pre¬ 
sent  frame.  First,  Bit  1  at  J1  is  brought  to  a  low  state  which,  when 
viewed  on  an  oscilloscope  signifies  the  end-of-frame.  Secondly,  the 
remaining  count  is  read  from  the  frame  generator  counter  to  provide  an 
exact  value  for  frame  time  remaining.  This  operation  was  used  during 
development  under  ICE- 80  control  and  has  no  function  for  the  real-time 
system.  Lastly,  the  wait  loop  is  entered  until  the  end  of  frame  interrupt 
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occurs.  (See  Section  5.4.  2.  )  At  this  point  control  passes  back  to  the 
beginning  of  the  simulator  loop  at  SIMLOOP  unless  a  console  request  is 
pending  from  the  operator.  If  such  a  request  is  pending  the  actions 
described  in  Section  6.  6.  3.  2  will  be  taken. 
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SECTION  6 

COMPUTER  PROGRAM  SYSTEM  USERS  GUIDE 


The  hardware  items  which  were  procured  for  this  project  were 
strictly  off-the-shelf  components.  These  components  were  capable  of 
being  modified  to  a  certain  extent.  However,  the  generalized  nature  of 
this  equipment  was  not  affected  by  any  of  the  modifications  which  were 
performed.  The  equipment  was  designed  to  be  largely  software  config¬ 
ured.  This  section,  therefore,  describes  the  software  which  is  necessary 
to  set  up  the  hardware  components  for  this  project,  perform  utility  func¬ 
tions,  and  conduct  the  real-time  simulation. 

6.  1  GENERAL  INFORMATION 

The  entire  control  loader  software  was  written  in  the  Intel  high- 
order  microcomputer  language  called  PLM  (PL/M- 80),  with  the  exception 
of  the  analog- to- digital  conversion  routine  which  was  performed  in  assem¬ 
bly  language.  The  programs  were  structured  into  a  utility  module,  a 
scan  module,  and  a  simulator  module.  As  the  name  implies  the  utility 
module  provided  system  support  in  the  form  of  calibration  and  test  rou¬ 
tines,  system  interface  procedures,  and  system  initialization.  The  scan 
module  causes  twelve  of  the  available  sixteen  A-to-D  converter  channels 
to  be  scanned  sequentially  and  the  converted  values  to  be  placed  in  the 
appropriate  RAM  locations  for  later  use.  The  simulator  module  contains 
the  frame  rate  generator,  simulator  initialization  routines,  and  the 
simulator  equations  themselves.  The  executable  machine  code  was 
placed  in  PROM  (programmable  read  only  memory).  The  variable  data 
and  equation  coefficients  are  placed  in  RAM  (Random  Access  Memory). 
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6.2  SOFTWARE  DEVELOPMENT 


The  software,  including  both  the  PLM  and  assembly  language 
modules,  was  developed  on  an  Intel  MDS  (Microcomputer  Development 
System).  The  complete  system  development  required  the  following  sys¬ 
tem  components: 

o  MDS  with  64K  of  memory 

o  Dual  density  floppy  disk  system  (dual  drive) 
o  System  console  (TTY) 
o  PROM  programmer 
o  In- circuit- emulator  (ICE-80) 
o  Line  printer 

The  MDS  supports  PLM  with  a  coupler  called  PLM80  and  an 
assembler  called  ASM80.  (The  reader  is  referred  to  the  appropriate 
language  and/or  operator's  manual  in  Volume  2  of  the  Computer  Program 
Documentation  (CPD).  )  Furthermore,  the  MDS  links  the  various  modules 
together  (including  the  PLM  library  module)  with  an  Intel  program  LINK. 
The  linked  program  is  subsequently  located  in  the  appropriate  memory 
addresses  with  another  Intel  program  LOCATE.  (See  ISIS  II  User's 
Guide.  )  The  executive  code  was  placed  in  PROM  by  employing  Intel's 
program  UPM  (see  Universal  PROM  Mapper  Operator's  Manual).  During 
the  development  phase,  the  memory  and  CPU  of  the  System  80/20  was 
emulated  by  the  MDS  through  the  use  of  Intel's  ICE- 80  In- Circuit- Emulator 
and  its  associated  software  program  called  ICE80.  (See  ICE- 80  Hardware 
Reference  Manual  and  Operator's  Manual.  ) 

6 .  3  SIMULA  TOR  EQ  UA  TIONS 

A  great  number  of  tasks  are  accomplished  in  the  SIMULATOR 
procedure  and  its  associated  procedures.  However,  before  discussing 
the  specific  mechanisms  involved,  a  general  discussion  is  needed  in 
order  to  relate  the  approach  taken  to  the  overall  problem.  Similarly  it 
is  necessary  to  discuss  equation  scaling  and  to  relate  the  actual  micro¬ 
computer  values  associated  with  each  parameter. 
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Each  of  the  individual  control  loading  force  components  in  some 
way  models  an  element  of  the  aircraft  control  system.  These  forces  are, 
in  general,  additive  as  shown  in  Figure  6.  1  even  though  they  may  be  the 
result  of  non-linear  processes.  However  the  total  solution  requires  that 
these  forces  be  logically  connected  to  accurately  represent  the  fully 
integrated  control  system. 

As  an  example  of  the  microcomputer's  flexibility,  consider  the 
forces  generated  for  a  single  axis  (e.  g.  pitch  control)  which  has  a  dead¬ 
band  due  to  rigging  slack  at  the  control  stick.  The  pilot  would  therefore 
experience  nearly  zero  force  within  the  deadband  which  is  described  as 
follows : 


ftot  ^fsp  +  Fvi  +  Fco  +  fbr1u(DB> 


+  F  +  F  +  F 

TR  VEL  AC 


(6.  1) 


where  the  above  terms  stand  for  total,  spring,  viscous,  coulomb,  break¬ 
out  travel  limit,  velocity  limit  and  aircraft  related  forces  respectively. 
The  -unit  operator  "U"  indicates  that  the  quantities  within  the  brackets  are 
nil  in  the  deadband. 


As  an  alternate  example,  consider  a  case  where  the  rigging  slack 
is  remote  from  the  stick.  The  coulomb  friction  due  to  pully  drag  may 
then  be  placed  outside  the  influence  of  the  deadband  with  the  resultant 
force  equation 


FTOT  =  fFSP+FVI  +  FBR]U(DB) 


+  F  +F  +F  +F 
CO  TR  VEL  AC 


(6.2) 


These  two  examples  represent  wiring  differences  in  an  analog  system 
but  only  software  differences  in  a  digital  system,  an  important  consider¬ 
ation  in  a  research  or  development  environment.  For  the  A-  10  model, 
the  deadband  is  very  small  but  follows  the  format  of  Equation  6.  1.  The 
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Figure  6.  1  Force  Component  Diagram  -  Single  Axis 


complete  pitch  force  equation  (from  Section  4.  5.  1)  then  becomes 

FTOTp  =  -tFSPp  +  FBRp  +  FCOp  +  -64Xp] 

spring  breakout  coulomb  viscous  , , 

(b.  3) 

U(DB)?  +  FTRp  -  (3NZ+.  026q) 

deadband  travel  bobweight  (aircraft) 

4  a 

where  X  is  the  velocity  in  inches -per- second,  N  and  q  are  the  normal 
and  angular  accelerations  from  the  airframe  computer  which  produce  the 
control  system  bobweight  effects.  The  force  is  calculated  in  pounds  and, 
of  course,  requires  a  sign  change  to  produce  the  required  opposing  force. 
Equation  6.  3  is  obviously  stylized  and  requires  special  handling  due  to 
the  non-linearities  involved. 

In  order  to  handle  the  non-linearities  of  such  a  system,  the  fre¬ 
quency  response  of  the  control  loader  must  be  considered.  The  nominal 
20  frames-per- second  for  digital  simulators  is  usually  sufficient  to  make 
the  pilot  believe  that  he  is  flying  in  a  parallel,  analog  world  as  evidenced 
by  his  visual  displays.  However,  the  pilot's  tactile  mechanism  is  cap¬ 
able  of  much  higher  frequency  response.  Empirical  studies  conducted  on 
the  McFadden  control  loader  revealed  frequency  components  of  1000  Hz 
and  higher.  As  one  might  expect,  these  components  are  experienced  at 
the  breakout  and  travel  limits  where  forces  suddenly  change.  To  satisfy 
the  ground  rules  of  information  theory  put  forth  by  Shannon,  the  micro¬ 
computer  should  ideally  be  framing  at  a  5000  Hz  rate  or  better.  How¬ 
ever,  this  project  demonstrated  that  quite  acceptable  results  can  be  had 
at  120  frames-per- second  by  judiciously  choosing  compensation  schemes. 
That  is,  by  optimizing  lead,  lag  and  gain  coefficients  in  the  individual 
component  force  calculations  relatively  sharp  breakouts  and  stops  were 
obtained. 

Various  techniques  were  attempted  to  achieve  the  proper  compensa¬ 
tion,  including  a  Tustin  recursion  method  to  approximate  the  desired 


* 


transfer  function.  However,  the  final  product  was  a  result  of  an  educated 
cut-and-try  effort.  For  example  consider  the  travel  limit  force  compo¬ 
nent  which  can  be  expressed  mathematically  as  a  recursion  relationship 


FTRp  *  Kp[Xp(N|+Xp(N.l)]  ♦  K^X 


(6.4) 


In  the  digital  implementation,  the  needed  lag  term  is  obtained  by  employing 


both  the  present  frame  value  for  travel  limit  displacement  X  (N)  and  the 

P 

previous  frame  value  X  (N-l).  The  gain  is  controlled  by  the  value  of  K 

P  P 

and  the  needed  lead  term  is  obtained  from  the  available  velocity  signal 


X  which  is  modified  by  the  constant  Kj.  The  unsealed  magnitudes  of 


P  '  >ljp‘ 

K^,  and  and  the  number  of  terms  in  the  recursion  portion  of  the  lag 

component  were  determined  empirically  with  the  final  values  set  at  Kp  =  6 

and  =  2.  The  breakout  term  of  Equation  6.  3  required  a  slight  lag 

compensation  augmented  by  a  lead  term  (Ksp  =  0.  3)  and  was  empirically 

structured  as 


FBRp  =  2*p  +  KBpXp  for  2 


X  \  <  2. 5 
Pf 


=  2.5  sign  (X  )  for  2  X  Z  2.  5 
P  P 


(6.5) 


Similarly,  the  coulomb  friction  term  required  compensation  to  offset  a 
tendency  to  "dither"  because  of  its  dependency  on  the  sign  of  the  velocity. 
In  this  case  a  simple  lag  was  implemented  by  employing  the  velocity 
value  as  follows: 


F°op  -  Xp 


for  |  X  <1.5 
P  1 


=  1.5  si;  * 


for  X  >1.5 
P  1 


(6.6) 


The  equations  executed  by  the  microcomputer  for  each  of  the 
respective  axes  are  summarized  as  follows: 


Pitch 


Refer  to  equations  6.  3,  6.  4,  6.  5,  and  6.  6  above. 
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1 
I 
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t  I 


Roll 


FtOTt 


=  -[4.  5Xr  +  FBRr  +  FC0R  +  -06Xr]U(DB)r 


spring 

FTRR 

travel 


breakout  coulomb 


(5N  +•  008p) 

y 


R 

viscous 


BRr 


limb  bobweight 

>BrX  “1  "“R 
,  t —  7  l\ 

R 


=  2XR  +  KBnX  for  2  |  XR|<  2.0 


=  2.0  sign  (XR)  for  2  XR  |  2  2- 0 


FcOt 


TRr 


*  XRf°r  |Xr|<1.5 
=  1.5  sign  (XR)  for  |  XR  |  4  5 

=  Kr  [Xr(N)  +  Xr(N-1)]  +  kLrxr 


where  KR  =  6  and  Kl^  -  ^ 


Yaw 


fTOty 

fBry 


-[15Xy  +  FBRy  +  FCOy  +  '  905Xy]U(DB)y 
2X„  +  KBvXv  for  2  I  XY  I  <  5.  0 


*Y  -°Y‘*Y  ]  Y 

=  5.0  sign  (XY)  for  2  |Xy  |z5.0 


F  CO-, 


=  XYfor  |XY|<  4.25 


FtR. 


=  4.25  sign  (XY)  for  |  Xy|  2  4.25 
=  Ky[Xy(N)  +  Xy(N-  1 )]  +  KLyXy 


where  Ky  =  6  and  KLy  =  2 
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(6.7) 


(6.8) 
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6.4  EQUATION  SCALING 
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The  first  step  in  scaling  the  equations  was  to  properly  determine 
sign  conventions.  Using  the  McFadden  control  loader  it  was  determined 
that  the  pitch,  roll  and  yaw  axes  are  positive  in  the  aft,  right,  and  right 
directions  respectively.  That  is,  the  position,  velocity  and  force  vectors 
for  the  pitch  axis  (for  example)  is  positive  aft.  (Refer  to  Table  4.  1  and 
Figure  4.  1.  )  To  further  clarify  this  point  consider  a  spring  force  acting 
on  the  pitch  stick  axis.  A  positive  (aft)  displacement  will  result  in  a 
negative  (forward)  force. 


The  second  step  in  the  scaling  process  was  to  determine  the  input 
and  output  sensitivities  and  then  formulate  these  sensitivities  and  the 
equation  coefficients  to  obtain  the  microcomputer  parameters.  On  the 
input  side,  the  position  and  velocity  values  (for  all  axes)  are  related  in 
inches  and  inches /second,  respectively.  The  force  output  is  related  in 
pounds.  The  microcomputer  converts  voltages  to/from  digital  values 
through  its  Analog- to- Digital  Converter  (ADC)  and  its  Digital-to- Analog 
Converter  (DAC).  Both  of  these  devices  have  a  12-bit,  bilateral  (+10  v) 
resolution.  However,  since  the  8080  microcomputer  operates  on  multi¬ 
ples  of  8  bits,  the  converter  bits  are  placed  in  the  most  significant 
positions  of  a  16-bit  word.  Therefore,  the  full  range  of  20  volts  (+10  v) 
can  be  represented- in  15  bits  or  2  ^  (65,  536)  counts.  In  other  words. 


,  .  .  65536  „  COUNTS 

the  A/D  conversion  factor  is  “ - or  327b.  8 


The  control 


20  v  V 

loader  sensitivity  terms,  therefore,  can  be  expressed  as  digital  values 

and  these  are  shown  in  Table  6.  1. 


In  order  to  perform  the  calculations  in  the  microcomputer,  each 
equation  coefficient  must  be  conditioned  by  the  proper  input  and  output 
sensitivity  values.  For  example,  if  the  viscous  friction  constant  was 
.  64  lbs /in/sec,  then  the  digital  value  which  represents  the  force  result¬ 
ing  from  a  digital  velocity  PDOT  is 
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TABLt  b.  I  LN±-'U  x  /  UU TrU  1  blijNbl  1 IV 1 1  JJlo 


Control 

Loader 

Voltage 

Digital 

Units 

Sensitivity 

Sensitivity 

Pitch 

1  V 

3277 

counts 

Displacement 

inches 

1  in 

in 

Velocity 

in 

1  V 

655 

counts 

sec 

5  in/ sec 

in/ sec 

1  V 

3277 

counts 

Norm.  Acc. 

G's 

1  G 

G 

Rot.  Acc. 

deg 

1  V 

819 

counts 

sec4 

4  deg/sec2 

deg/sec^ 

lb 

1  V 

218 

counts 

Force 

15  lb 

lb 

Roll 

inches 

1  V 

3277 

l 1 

counts 

Displacement 

1  in 

in 

Velocity 

in 

1  V 

546 

counts 

sec 

6  in/ sec 

in/ sec 

1  V 

3277 

counts 

Norm.  Acc. 

G's 

1  G 

G  | 

Rot.  Acc. 

deg 

1  V 

1638 

i 

counts 

sec4. 

2  deg / sec2 

deg / sec2 

lb 

1  V 

328 

counts 

Force 

10  lb 

ib 

Yaw 

Displacement 

inches 

1  V 

1  in 

3277 

counts 

in 

in 

1  V 

655 

counts 

Velocity 

sec 

5  in/ sec 

in  /  sec 

lb 

1  V 

164 

counts 

F  orce 

20  lb 

lb 

i 
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.  64 


LB 


IN/SEC 


218 


COUNTS 

LB 


655 


COUNTS 

IN/SEC 


PDOT  counts 


=  -.2133  PDOT  counts  (see  Table  6.2) 

In  other  words,  the  digital  value  PDOT  would  be  read  from  the  A/D  con¬ 
verter  and  then  multiplied  by  the  dimensionless  microcomputer  coefficient, 
0.2133.  The  resulting  value  is  then  complimented  to  give  the  proper  sign 
and  thus  produce  the  digital  component  due  to  spring  force  F  .  may 

then  be  added  with  other  components  before  being  written  to  the  Digital- 
to- Analog  Converter  (DAC). 

To  perform  the  above  multiplication  ordinarily  requires  that  the 
operation  be  carried  out  in  floating  point  format.  The  input  value  PDOT 
must  be  converted  to  floating  point,  the  multiplication  performed,  and 
the  result  converted  back  to  fixed  point  (integer)  format.  This  is  a  very 
time  consuming  process  and,  therefore,  a  technique  was  devised  to  pro¬ 
duce  the  desired  product  by  integer  multiplication.  The  SBC  310  High 
Speed  Math  Board  produces  a  32- bit  integer  product  from  two  16-bit 
integer  operands.  This  32- bit  product  can  be  considered  to  consist  of 
a  low  order  16-bit  word  and  a  high  order  16-bit  word  which  as  a  weight 
2^  (65536)  times  larger  than  the  low  order  word.  The  control  loading 
calculations  must  always  result  in  a  16-bit  value  since  the  DAC  only 
accepts  16-bits.  Ordinarily,  the  desired  result  of  a  multiplication 
involving  an  operand  (PDOT)  which  is  less  than  65536  and  a  coefficient 
(e.  g.  0.2133)  would  itself  be  less  than  65536  and  it  would  reside  in  the 
low  order  word  of  the  SBC  310.  However,  if  the  coefficient  is  scaled  up 
by  a  factor  of  65536  then  the  desired  result  will  reside  in  the  high  order 
word.  The  microcomputer  coeiflcient  in  this  case  is 

KPVISC  =  0.2133  X  65536  =  13981 


The  equation  implemented  in  the  microcomputer  is  then 
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F  =  -  HIGH  (KPVISC*  PDOT)  COUNTS 


where  "HIGH"  refers  to  employing  the  high  order  16-bit  word  of  the  32- 
bit  result  of  the  SBC  310. 


Figure  6.  2  illustrates  this  integer  multiplication  algorithm  which  is 
used  throughout  the  simulator  processing.  The  coefficient  KPVISC  is 
loaded  in  the  lower  sixteen  bits  of  operand  register  2  on  the  high  speed 
math  board.  Likewise,  the  absolute  value  of  the  velocity  PDOT  as  read 
from  the  ADC  is  placed  in  the  lower  sixteen  bits  of  operand  register  1. 

The  integer  multiplication  operation  "TIMES"  is  invoked  (via  the  PER¬ 
FORM  procedure)  and  the  32-bit  product  of  the  unsigned  multiplication 
(the  reason  for  using  the  absolute  value)  is  placed  in  operand  register  1. 
Since  KPVISC  was  scaled  up  by  2^  the  properly  scaled  product  is  also 
scaled  up  by  2^  and  therefore  resides  in  the  high  order  half  of  register  1. 


The  net  result  of  this  technique  is  a  very  distinct  speed  advantage: 
200  microseconds  for  a  complete  integer  multiplication  versus  1000 
microseconds  for  a  complete  floating-point  multiplication  (float/fix 
conversion  included).  All  calculations  are  now  carried  out  in  the  micro¬ 
computer  in  integer  format.  Table  6.2  contains  the  values  of  pertinent 
coefficients  for  microcomputer  processing.  The  other  terms  (without 
scaled  values)  are  parameters  in  the  total  force  output  but  are  not  coeffi¬ 
cients  for  multiplication.  For  example,  if  the  pitch  coulomb  value  of 

1.  5  pounds  is  to  be  added  to  the  total  force,  then  the  integer  value  of  328 
COUNTS 

(1.  5  LB  X  218  —  - )  is  added  to  the  integer  force  value  which 

Lib 

eventually  is  written  to  the  output  DAC. 


The  springforce  modeled  by  the  microcomputer  can  be  either 
linear  or  non-linear.  In  the  case  of  the  A-  10  the  pitch  axis  spring  is  the 
only  non-linear  force  producer.  The  other  axes,  roll  and  yaw,  are 
linear.  Furthermore,  the  pitch  axis  is  also  non- symmetrical  in  the 
fore  and  aft  forces  which  it  produces. 
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TABLE  6.2  MICROCOMPUTER  COEFFICIENTS 


TERM 


VALUE 


SCALED 

VALUE 


INTEGER  VALUE 
(X  64K) 


The  general  procedure  which  is  followed  to  produce  the  spring 
force  values  is  that  of  calculating  a  straight  line  if  the  form 

y  =  mx  +  b 

where  "m"  is  the  spring  coefficient  (slope),  "x"  is  the  displacement,  and 
"b"  is  the  offset  force.  For  a  totally  linear  spring  the  offset  "b"  is  zero. 
Non-linear  springs,  on  the  other  hand,  are  calculated  in  a  piecewise 
manner  where  the  first  segment  (nearest  the  origin)  will  have  an  offset 
"b"  equal  to  zero  and  all  other  segments  will  have  a  non-zero  offset. 
Figure  6.  3  illustrates  the  piecewise  approximation  of  the  pitch  spring 
force  curve.  The  various  breakpoints  and  offsets  are  shown  on  the  curve 
and  the  spring  coefficients  were  calculated  from  the  slope  of  each  seg¬ 
ment.  The  decimal  values  reflect  the  real  world  parameter  and  the 
integers  are  the  values  which  were  used  in  the  microcomputer  calcula¬ 
tions.  Table  6.  3  summarizes  these  microcomputer  parameters. 

TABLE  6.  3  PITCH  SPRING  PARAMETERS 

SEGMENTS 


Name 

1 

2 

3 

4 

5 

KPSOFFA 

KPSBRKA 

KPSPRINGA 

KPSOFFF 

KPSBRKF 

KPSPRINGF 

0 

0 

23522 

851 

4260 

10427 

1373 

11469 

7445 

0 

0 

21840 

341 

4915 

17300 

These  parameters  were  placed  in  arrays  corresponding  to  the  names  at 

the  left  and  the  array  length  obsiously  corresponds  to  the  number  of 

segments  in  the  curve.  As  an  example  of  a  spring  force  calculation 

within  the  microcomputer  consider  a  situation  where  the  stick  is  displaced 

2  inches  aft.  The  converted  digital  value  PITCH  would  be  6554  (2  IN  X 
COUNTS 

3277  - — ).  The  microcomputer  determines  that  this  value  lies  in 

IN 

segment  number  2  on  the  spring  force  curve.  The  final  spring  force 
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digital  value  is  calculated  by  integer  multiplying  the  PITCH  value  by  the 
slope  KPSPRINGA(2)  and  adding  the  offset  KPSOFFA(2).  Thus 

F  =  HIGH  (KPSPRINGA(2)  •  PITCH)  +  KPSOFFA(2) 

=  HIGH  (10427  •  6554)  +  851 
=  1043  +  851  =  1894  COUNTS  (8. 69  LBS) 

6.  5  EQUATION  IMPLEMENTATION 

The  equations  of  Section  6.  3  are  implemented  in  the  final  software 
in  a  form  such  that  the  microcomputer  and  the  high  speed  mathematics 
board  perform  unsigned  (positive)  integer  multiplication  of  16-bit  quan¬ 
tities.  This  operation  is  carried  out  by  specifically  loading  the  operands 
into  the  mathematics  board  and  retrieving  the  results  as  described  in 
Section  6.4.  Because  of  this  process,  the  equations  which  are  executed 
cannot  be  expressed  in  FORTRAN- like  statements.  However,  it  may 
perhaps  be  helpful  to  express  the  mathematical  equations  of  Section  6.4 
in  a  standard  format  using  the  mnemomics  of  the  PLM  software.  There¬ 
fore,  the  following  paragraphs  are  a  summary  of  these  microcomputer 
program  "pseudo- statements.  "  This  summary  should  be  reviewed  in 
conjunction  with  the  detailed  explanation  in  Section  5.4.4,  Simulator 
Processing. 

6.  5.  1  Pitch  Equations 

The  digital  value  of  the  pitch  force  is  written  to  the  appro¬ 
priate  analog  line  through  digital- to -analog  converter  DACO.  Therefore, 

DACO  is  equated  to  either  the  limit  force  or  the  linear  force,  depending 
on  the  magnitude  of  the  pitch  displacement  (see  Figure  5.  3).  The  pitch 
limit  force  is  composed  of  a  linear  term,  a  lag  term  and  a  lead  term  and 
can  be  expressed  in  the  aft  direction  as: 

DACO  =  -  KPLIMF  (PITCH- PLIMAFT)  +  PLIMOLD(l) 


+  KPLIMLEAD  (PDOT) 


Subsequently  for  the  next  frame 

,  PLiIMOLD  (1 )  =  -  KPLIMF  (PITCH- PLIMAFT) 

For  the  linear  portion  of  the  force  range,  the  following 
’  series  of  statements  express  the  calculations  which  take  place  to  incor¬ 

porate  each  of  the  modeled  parameters: 

1 

Spring  and  Breakout 

,  PTOT  =  (PITCH+PTRIM)  KPSPR1NGA(B2 )  +  KPSOFFA(B2) 

+  KPBRAK 

1 

where  B2  is  the  spring  segment  number. 

Breakout  Lead 

PTOT  =  PTOT  +  KPBRKLEAD  (PDOT) 

Bobweight  Effects 

1  PTOT  =  PTOT  +  KNZ  (NZ) 

1  PTOT  =  PTOT  +  KQDOT  (QDOT) 

i 

Integration  and  Output 

DACO  =  PTOTOLD  +  PTOT/2 
PTOTOLD  =  PTOT/2 

The  above  equations  would  be  modified  for  a  forward  stick  displacement 

i 

by  appropriately  replacing  PLIMAFT,  KPSPRINGA,  and  KPSOFFA  with 
PLIMFOR,  KPSPRINGF,  and  KPSOFFF. 

I 

6.  5.  2  Roll  Equations 

J  The  analog  value  of  the  roll  forces  is  produced  by  DAC1 

and,  similar  to  the  pitch  equations,  the  roll  equations  can  be  expressed 
for  the  limit  force  as 

DAC 1  =  -  KPLIMF  (ROLL- RLIMRT)  +  RLIMOLD(l) 

t 

+  KRLIMLEAD(RDOT) 
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RLIMOLD(l)  =  -  KRLIMF  (ROLL.-  RLIMRT) 


For  the  linear  portion  of  the  force  range,  the  following  series 
of  statements  express  the  calculations  which  take  place  to  incorporate  each 
of  the  modeled  parameters 

Spring  and  Breakout 

RTOT  =  (ROLL+RTRIM)  KRSPRINGR(B2)  +  KRSOFFR(B2) 

+  KRBRAK 

where  B2  is  the  spring  segment  number 
Breakout  Lead 

RTOT  =  RTOR  +  KRBRKLEAD  (RDOT) 

Viscous  and  Coulomb  Friction 

RTOT  =  RTOT  +  KRVISC  (RDOT)  +  KRCOUL 

Bobweight  Effects 

RTOT  =  RTOT  +  KNY  (NY) 

RTOT  =  RTOT  +  KPPDOT  (PPDOT) 

Integration  and  Output 

DAC1  =  RTOTOLD  +  RTOT/2 
R  TO  TOLD  =  RTOT/2 

The  above  equations  would  be  modified  for  a  left  stick  displacement  by 
appropriately  replacing  RLIMRT,  KRSPRINGR  and  KRSOFFR  with 
RLIMLT,  KRSPRINGL,  and  KRSOFFL. 

6.  5.  3  Yaw  Equations 

The  analog  value  of  the  yaw  force  is  produced  by  DAC2  and, 
similar  to  the  pitch  and  roll  equations,  the  yaw  equations  can  be  expressed 
for  the  limit  force  as 


DAC2  =  KYLIMF  (YAW-  YLIMRT)  +  YLIMOLD(l)  +  KYLIMLEAD  (YDOT) 
Y  LI  MOLD  =  -  KYLIMF  (YAW-  YLIMRT) 


For  the  linear  portion  of  the  force  range,  the  following  series  of  statements 
express  the  calculations  which  take  place  to  incorporate  each  of  the  modeled 
parameters. 

Spring  and  Breakout 

YTOT  =  (YAW+YTRIM)  K  YSPRINGR(B2)  +  KYSOFFR(B2) 

+  KYBRAK 

where  B2  is  the  spring  segment  number. 

Breakout  Lead 

YTOT  =  YTOT  +  KYBRKLEAD  (YDOT) 

Viscous  and  Coulomb  Friction 

YTOT  =  YTOT  +  KYVISC  (YDOT)  +  KYCOUL 

Integration  and  Output 

DAC2  =  Y  TO  TOLD  +  YTOT/2 
YTOTOLD  =  YTOT/2 

The  above  equations  would  be  modified  for  a  left  rudder  displacement  by 
appropriately  replacing  YLIMRT,  KYSPRINGR,  and  KYSOFFR  with 
YLIMLT,  KYSPRINGL,  and  KYSOFFL. 

6.  6  HARDWARE  INTERFACE  DESCRIPTION 

Interfacing  the  microcomputer  with  the  control  loader  and  the  host 
computer  is  very  simple.  It  requires  only  two  connectors,  one  for  the 
analog  input  board  (SBC  711)  and  one  for  the  analog  output  board  (SBC  724). 
If  a  teletype  is  to  be  used  it  should  be  connected  to  the  SBC  530  adapter 
supplied  with  the  system.  If  it  is  desirable  to  monitor  the  frame  times 
with  an  oscilloscope,  one  additional  conncetor  is  necessary  to  gain  access 


to  J1  on  the  SBC  80/20  board.  The  interface  specifications,  pin  connec¬ 
tions,  and  other  relevent  information  can  be  gathered  from  the  appropri¬ 
ate  hardware  reference  manuals  (HRM)  for  the  SBC  711,  SBC  724,  and 
SBC  80/20  and  the  data  sheets  for  the  SBC  530.  The  following  descrip¬ 
tions  are  provided  as  a  reference  for  interfacing  the  control  loading  sys¬ 
tem  properly. 

The  three  SBC  boards  (711,  724,  and  80/20)  all  require  the  same 
type  of  50-pin  PC  edge  connector.  The  following  list  summarizes  the 
manufacturers  and  the  part  numbers  for  suitable  mating  connectors.  The 
technician  is  advised  that  the  connector  manufacturer's  numbering  sys¬ 
tem  may  be  different  from  Intel's  and  that  Intel's  numbering  must  be  used 
regardless  of  the  pin  numbers  etched  on  the  connectors. 


50-pin  PC  Mating  Connectors 


Connector  Type 

Vendor 

Part  No. 

Flat  Cable 

3M 

3415-0001 

AMP 

2-86792-3 

Soldered 

AMP 

2-583715-3 

VIKING 

3VH25/1JV-5 

TI 

H3 12125 

Wire-wrap 

TI 

VIKING 

H312125 

3VH25/1JND-5 

CDC 

VPB01E43A00A1 

ITT 

EC4A050A1A 

Crimp 

AMP 

1-583717-1 

6.6.  1  Analog  Input  Interface 

The  analog-to-digital  conversions  are  handled  by  the  Intel 
analog  input  board,  SBC  711.  This  board  is  capable  of  making  channel- 
to- channel  conversions  at  a  16KHZ  rate  with  an  overall  accuracy  of  0.  05%. 
The  board  is  configured  to  accept  sixteen  single- ended  channels  of  analog 
signals  through  a  50-pin  PC  edge  connector  (J2).  The  pin  assignments 
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for  the  respective  channels  can  be  found  on  page  2-10  of  the  SBC  711 
HRM.  The  proper  methods  of  cabling  can  also  be  found  in  Figure  2.  5 
of  that  manual.  Furthermore  the  user- option  modifications  made  to 
this  board  can  be  found  in  the  following  subsections  of  this  manual  under 
Hardware  Modifications.  The  following  list  summarizes  the  use  of  the 
analog  input  channels  for  the  control  loader. 

J2  PIN  CHANNEL  VARIABLE 


4 

0 

PDOT 

8 

1 

PITCH 

12 

2 

NZ 

16 

3 

QDOT 

20 

4 

RDOT 

24 

5 

ROLL 

28 

6 

NY 

32 

7 

PPDOT 

6 

8 

YDOT 

10 

9 

YAW 

14 

10 

PTRIMSIG 

18 

11 

RTRIMSIG 

12-15 

SPARE 

6.6.2  Analog  Output  Interface 

The  digital-to-analog  conversions  are  handled  by  the  Intel 
analog  output  board,  SBC  724.  This  board  is  capable  of  making  D/A 
conversions  with  12-bit  resolution  with  an  overall  accuracy  of  0.  05%. 

The  board  is  configured  to  produce  four  analog  output  channels  through  a 
50-pin  PC  edge  connector  (Jl).  The  pin  assignments  for  the  respective 
channels  can  be  found  on  page  2-8  of  the  SBC  724  HRM.  The  proper 
methods  of  cabling  for  the  outputs  can  be  found  in  Figure  2.  3  of  that 
manual.  Furthermore  the  user- option  modifications  made  to  this  board 
can  be  found  in  the  following  subsection  of  this  manual  under  Hardware 
Modifications.  The  following  list  summarizes  the  use  of  the  analog  out¬ 
put  channels  for  the  control  loader. 
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J1  PIN 


CHANNEL  • 


VARIABLE 


42 

0 

DAC0  (PITCH  FORCE 

36 

1 

DAC1  (ROLL  FORCE) 

30 

2 

DAC2  (YAW  FORCE) 

3 

SPARE 

6.  6.  3  Teletype  Interface 

Serial  communication  with  the  SBC  80/20  is  conducted 
through  a  26-pin  PC  edge  connector  (J3)  on  the  SBC  80/20  circuit  board. 
(See  page  5-5,  SBC  80/20  HRM.  )  However,  this  interface  is  designed 
for  an  RS232C  (CRT)  type  of  terminal.  To  interface  a  teletype  (TTY)  an 
adapter,  the  SBC  530,  is  necessary  and  is  supplied  with  the  control  load¬ 
ing  microcomputer.  This  adapter  converts  the  RS232C  signals  to  20  ma 
current  loops.  It  required  no  modification  and  merely  plugged  into  J3  on 
the  SBC  80/20.  The  teletype  connector  on  the  SBC  530  (J3)  is  a  standard 
DB25S  (female)  with  the  following  pin  assignments: 


PIN 

FUNCTION 

25 

TTY  TX  DATA  RETURN 

13 

TTY  TX  DATA 

24 

TTY  RX  DATA  RETURN 

12 

TTY  RX  DATA 

Thus,  the  Air  Force  must  provide  a  teletype  with  a  DB25P  (male)  con¬ 
nector  and  the  above  connections. 

6.6.4  Frame- Time  Interface 

It  may  be  desirable  to  monitor  the  frame-time  information 
concerning  the  control  loader  microcomputer.  This  information  is  avail¬ 
able  at  the  SBC  80/20  connector  J1  (see  SBC  80/20  HRM,  p.  5-3)  and  is 
summarized  as  follows: 

PIN  BIT  PORT 

48  0  1 

46  1  1 

49 


FUNC  TION 

Frame -available  time 
Frame-used  time 
Ground 


The  SBC  80/20  has  six  digital  I/O  ports  of  eights  bits  each.  The  amount 
of  frame -available  time  is  displayed  by  an  alternating  voltage  level  on 
Bit  0  of  Port  1  (pin  48,  Jl).  The  amount  of  frame-used  time  is  displayed 
by  a  high  voltage  (5V)  level  at  Bit  1  of  Port  1  (pin  46,  Jl).  This  frame- 
used  time  is  a  function  of  the  mathematical  operations  used  in  calculating 
the  respective  control  forces.  The  pulse-width  will  therefore  vary  as  the 
controls  of  the  loading  system  are  moved.  Figure  6.4  illustrates  the 
nature  of  these  signals.  Monitoring  these  signals  has  the  advantage  that 
the  user  can  assure  himself  that  a  parameter  change  has  not  resulted  in 
any  framing  errors  and  that  sufficient  frame  time  remains  for  further 
changes. 


Bit  0  - 

Port  1  _ 

|  FRAME  TIME 
'  AVAILABLE 


Bit  1  - 

Port  1  _ 

,  FRAME  TIME 
I  USED 


Figure  6.4  Frame  Time  Pulses 
6.  7  SYSTEM  OPERATION 

The  microcomputer  carries  with  it  a  great  deal  of  simplicity.  Its 
operation  does  not  require  a  high  degree  of  skill  in  the  digital  sciences  or 
computer  technology.  The  following  paragraphs  relate  the  tasks  which 
the  system  operator  must  accomplish  to  initiate  the  control  loading  simu¬ 
lator  or  any  of  the  other  options. 
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6.  7.  1  Interfacing 

The  minimum  "black  box"  configuration  requires  that  the 
analog  inputs  be  connected  to  the  control  loader  and  host  computer  as 
described  in  Section  6.  6.  1.  In  addition,  the  analog  outputs  must  be  con¬ 
nected  to  the  control  loader  as  described  in  Section  6.  6.  2.  The  micro¬ 
computer  is  therefore  a  stand  alone  device  as  illustrated  in  Figure  1.  1. 

If  the  operator  desires  to  change  a  parameter  or  execute  any  of  the  self¬ 
test  features  built  into  the  microcomputer,  a  teletype  must  be  connected 
to  the  SBC  530  TTY  adapter  as  described  in  Section  6.  6.  3. 

6.7.2  Power  Up  and  Simulator  Execution 

In  the  minimum  "black  box"  configuration  described  above, 
the  only  required  operation  is  to  apply  power  to  the  SBC  80/20  by  depres¬ 
sing  the  "power  on"  switch  on  the  left  side  of  the  front  panel.  The  simu¬ 
lator  is  automatically  entered  and  the  system  is  ready  for  immediate  use 
with  the  control  loading  system. 

6.  7.  3  Optional  Features 

The  system  operator  may  elect  to  use  some  of  the  options 
associated  with  the  microcomputer.  He  may  elect  to  reset  both  the  hard¬ 
ware  and  software  through  the  use  of  the  RESET  button  on  the  right  side 
of  the  front  panel.  If  he  connects  a  teletype  to  the  system  he  may  change 
parameters  and/or  initiate  one  of  the  self-test  features. 

6.  7.  3.  1  Reset 

The  CPU  is  equipped  with  a  "power-on  reset" 
feature  such  that  .  5  second  reset  pulse  is  produced  when  power  is  first 
applied.  If  the  operator  depresses  the  reset  button  on  the  right  side  of 
the  front  panel  the  same  action  will  be  taken  as  when  the  power  is  first 
applied,  except  that  the  reset  level  remains  active  as  long  as  the  button 
is  held. 
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caution 


When  the  reset  button  is  depressed  the  analog  out¬ 
put  board  commands  all  of  the  DAC’s  to  go  to  -lOv. 

Caution  must  be  taken  to  disconnect  or  otherwise 
disable  the  control  loader  so  that  the  servoes  are 
not  commanded  to  go  to  the  negative  limit.  A  hard¬ 
ware  modification  can  be  made  to  correct  this 
situation  if  necessary. 

6.7. 3. 2  Parameter  Changes 

The  operator  may  enter  parameter  changes  by 
first  depressing  a  key  (any  key)  on  the  teletype  console  while  the  simula¬ 
tor  is  active.  This  action  will  cause  the  simulator  loop  to  be  temporarily 
interrupted  and  the  loading  on  the  stick  and  rudder  will  be  zeroed  (all 
DAC's  =  Ov).  The  operator  is  presented  with  the  query 

CHANGE  PARAMETER?  (Y  or  N) 

If  he  responds  in  the  negative  (N)  the  system  will  assume  he  wishes  to 
execute  a  self-test  program.  If  he  responds  in  the  positive  (Y)  the  sys¬ 
tem  will  pursue  this  request  further  by  typing 

PARAMETER  NUMBER? 

The  processor  is  now  waiting  for  the  number  of  the  parameter  to  be 
changed  (see  Section  6.  1  and  5.  4.  4.  1).  The  parameters  and  the 
associated  numbers  are  listed  in  Table  5.  1.  If  the  operator  depresses 
the  carriage  return  without  inputting  a  parameter  number  the  processor 
immediately  returns  to  the  simulator  loop. 

CAUTION 

The  stick  and  rudders  should  be  placed  in  a  position 
close  to  neutral  to  prevent  rapid  build-up  of  forces. 

If,  on  the  other  hand,  the  operator  selects  one  of 
the  parameters,  the  processor  will  display  that  parameter's  present 
value,  e.  g. 


6-25 


PRESENT  VALUE  =  23522 


The  system  then  asks  for  a  new  value  by  typing 

NEW  VALUE? 

If  the  operator  inputs  a  carriage  return  without  first  inputting  a  value, 
that  parameter  remains  unchanged  and  control  passes  back  to  the 
"parameter  number"  question.  This  feature  allows  the  operator  to 
interrogate  parameters  without  changing  them.  Of  course  if  he  does 
supply  a  valid  integer  value  {£ 6553 5),  that  parameter  will  be  changed 
appropriately.  Once  again,  the  parameter  change  routine  is  terminated 
and  the  simulation  is  resumed  by  typing  a  carriage  return  immediately 
after  being  asked  for  a  parameter  number. 

6.  7.  3.  3  Self- Test  Programs 

If  the  operator  desires  to  execute  a  calibration  or 
test  program  while  the  simulator  is  operating  he  must  first  depress  a 
key  (any  key)  on  the  teletype  console.  This  action  terminates  the  simula¬ 
tor  loop  and  causes  the  system  to  ask  the  operator 

CHANGE  PARAMETER?  (Y  OR  N) 

The  response  must  be  negative  (N)  for  which  the  system  will  enter  the 
executive  program  as  evidenced  by  the  console  message: 

CONTROL  LOADER  EXECUTIVE 

WHICH  PROGRAM? 

The  operator  may  now  select  any  of  the  self  test  programs  (0  through  4)  by 
typing  the  appropriate  number.  (See  Section  5.  2.  7  for  a  complete  descrip¬ 
tion  of  these  programs.  )  At  the  completion  of  a  program  control  passes 
back  to  the  executive.  However,  if  program  5  is  selected,  control  passes 
back  to  the  simulator;  that  is,  all  simulator  parameters  are  reinitialized 
and  the  simulator  loop  is  entered. 
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fl  APPENDIX  A 

MODULE  FLOW  CHARTS 

« 

This  section  contains  the  detailed  module  flow  charts  referenced  in 
i  Section  5.  Each  flow  chart  corresponds  to  the  procedure  of  the  same  name 

as  described  in  that  section. 
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